Summary: | www-client/seamonkey should support Python 3 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Arfrever Frehtes Taifersar Arahesis <arfrever.fta> |
Component: | Current packages | Assignee: | Myckel Habets <gentoo-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dev, gentoo-bugs, jasmin+gentoo, kripton, mgorny, mike, mozilla, sam, voron1 |
Priority: | Highest | Keywords: | PullRequest |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=698978 https://github.com/BioMike/gentoo-seamonkey-patches/issues/1 https://github.com/gentoo/gentoo/pull/32682 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 904392, 912969 | ||
Bug Blocks: | 694800 |
Description
Arfrever Frehtes Taifersar Arahesis
2019-10-31 03:04:51 UTC
Current stable spidermonkey version 2.53.6 supports py3. Bug can be closed. www-client/seamonkey-2.53.6 through mozcoreconf-v6.eclass depends on dev-lang/python:2.7[ncurses,sqlite,ssl,threads(+)]. @mozilla, as far as I can see seamonkey is the only package still using mozcoreconf-v{5,6}.eclass actively. The firefox and spidermonkey ebuilds have migrated away from using these eclasses. What is the future of those eclasses? Are they going to be retired? Or are there plans to update them to remove Python 2.7 support and have firefox and spidermonkey re-use them? (In reply to Myckel Habets from comment #3) > What is the future of those eclasses? Are they going to be retired? As long as something still uses them, I don't see a reason for removal. > Or are there plans to update them to remove Python 2.7 support If no package requires python-2.7 anymore we should indeed remove python-2.7 support from the eclasses. Unfortunately it does look like some older spidermonkeys still depend on the eclass and therefore possibly python-2.7. Now looking into removing those older spidermonkeys takes us to many places, as some packages in tree still depends on those. > and have firefox and spidermonkey re-use them? Truthfully I'd like to return the eclass support to Firefox, Spidermonkey and Thunderbird, since all these are very similar. But I guess the problem was that these functions update often between major releases, so therefore it's easier to carry them in the ebuilds. Seeing that there are two versions of these eclasses in tree, would it be possible to add a new one with a bumped version (v7) that does not contain python2.7 support? We can than keep the old ones for the old Spidermonkey, but let Seamonkey (and later Firefox and newer Spidermonkeys) use the newer one. As for FF/SpM reusing them, even if they don't want to do this at this point it gives me enough motivation to have look into this. If seamonkey is currently the only one actively using it, I'll try to make it better suited for Seamonkey (with keeping FF/SpM in mind) and than we can at a later point determine if it suits to re-add to the other packages. (In reply to Myckel Habets from comment #5) > Seeing that there are two versions of these eclasses in tree, would it be > possible to add a new one with a bumped version (v7) that does not contain > python2.7 support? We can than keep the old ones for the old Spidermonkey, > but let Seamonkey (and later Firefox and newer Spidermonkeys) use the newer > one. > I quite honestly don't see the point of adding new eclass just to "drop" python-2.7 support. Nothing would change with that. Since seamonkey is the only one using -v6, if you are sure it doesn't require python-2.7 to build, we can just drop the BDEPEND from that eclass. I'd imagine the PYTHON_COMPAT declared in seamonkey, and BDEPEND="${PYTHON_DEPS}" in the ebuild is enough to declare the required python interpreter to build seamonkey. > As for FF/SpM reusing them, even if they don't want to do this at this point > it gives me enough motivation to have look into this. If seamonkey is > currently the only one actively using it, I'll try to make it better suited > for Seamonkey (with keeping FF/SpM in mind) and than we can at a later point > determine if it suits to re-add to the other packages. Well, _I_ would prefer to move the functions from ebuilds to an eclass. But: 1: I kind of hope the main mozilla maintainers returns who opposed to that idea, 2: it doesn't bother _that_ much having them in the ebuilds and 3: I guess history did show that we need to modify the eclass too often. Also I imagine the eclass-way breaks overlays and whatever downstreams are relying on us packaging it. If the rest of the logic is the same, it'd make more sense to just have a variable that seamonkey can set to allow Python 2 usage. Whissi did intend on merging the new logic back into an eclass but his plans Kay have changed. (In reply to Sam James from comment #7) > If the rest of the logic is the same, it'd make more sense to just have a > variable that seamonkey can set to allow Python 2 usage. I think fixing the python2 issue should have the main focus for now, rest can come later. I think it is better to remove python2 usage althogether, than to add a variable for something that is clearly EoL. I did a quick check this morning by removing the Python 2 support code from the eclass and see if Seamonkey would build... it didn't. I got an exception where it tried to setup third party supplied setuptools, pip and wheel to setup a "virtual environment". It was pip that caused the exception btw. I'll have to dive into this deeper. Another dependency (through the "crypt" USE flag) that requires python2 is <x11-plugins/enigmail-2.1.0. Seamonkey seems to be the only user of that enigmail version as well. So, to completely go Python 3, that has to be tackled as well. Searching through the code, I've encounter various spots that call python2.x, which might give issues that surface downstream the build process. Enigmail seems to not support Seamonkey since 2019. I'm considering dropping that from the ebuild. Is seamonkey based on firefox? What version is the latest seamonkey based on? There was a pip-related error that got patched out in firefox-95, but upstream made it variable-controllable for 96. Although, if it was based on firefox, it feels weird that python2 is still required. I haven't checked seamonkey ebuild, but maybe something similar is happening here? Does it work _without_ pip? I can't find an upstream bug about python3 support. However, in future, I do wonder if setting up some sort of virtualenv is possible while building it with portage. I've opened a bug on their bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1756371 Current Seamonkey releases don't support Python3 building. One option might be porting the build code ourself, although that would be quite some work. (In reply to Joonas Niilola from comment #10) > Is seamonkey based on firefox? What version is the latest seamonkey based > on? Comment from one of the devs on the community forum: The SeaMonkey 2.53 line was orginally based on the latest Gecko 56 code. Now about 11000 updates later it is basically a fork. Security updates up to 91.4 are in 2.53.11b1 pre and the upcoming 2.53.10.1. Ping. The cost of backporting vulnerability fixes to Python 2 at this point is humongous, and it only covers vulnerabilities that were still present in modern versions of Python 3. This whole package is a death trap. Yes, I'm aware of that and would like to see Python 2 go asap as well. Past few months I've been working with upstream to get Python3 support into their build system. Most of it should be in now, but is still untested on a Python3-only system. My plan was to start on that this week, see what's still missing or would require gentoo-specific patches to get it building without python2. Thanks. Please keep us posted. Here is an update. Next release will be 2.53.14, which won't support Python 3 yet. Since the last update I've been pushing more patches upstream to get closer to Python 3 support, but ran into other parts (l10n) of the build system that needs to be updated first (unicode issues). Done most part of that, but for some reason it isn't working yet. Working with upstream to get that resolved. After that Python 3 support seems to be close, hopefully in time for 2.53.15. Anything new to report? FWICS .15 still requires py2.7. I managed to get the configure, build and packaging phase to use python3, but starting Seamonkey results in a segfault at start up (it's the second already, but I managed to get the first fixed). Some of the python scripts generate files that sit in between javascript and c++ code and I had to make some considerable changes to those scripts to get it working. This suggesting that the problem is somewhere in this spot. I hoped that this part would have gone a bit smoother. An update: I received a message from upstream this morning that the final patches that should result in Python 3-only building have been included into their patch tree. I hope this means 3.53.17 can be build with Python 3 and that Python 2 isn't needed any more. In the case the patches haven't been fully included into the release, I'll try to provide a seperate patch that does this anyway. Seamonkey 2.53.17 has finally been released by upstream. With the beta I tested that this version doesn't need Python 2.7 to be installed any more. Suggested path of fixing this bug: 1) Seamonkey 2.53.17 in portage. I plan to have this done by the end of the weekend. 2) Stabilize Seamonkey 2.53.17 (maybe fast track?) 3) Drop older versions. 4) Drop the Python magic in the mozcoreconf-v6 eclass commit dcb7f431a283a8e392a546198a1f3d8de5e5db68 (origin/master, origin/HEAD) Author: Myckel Habets <gentoo-bugs@habets-dobben.nl> Date: Sun Aug 6 21:18:14 2023 +0200 www-client/seamonkey: Update to version 2.53.17. - Bumps seamonkey to version 2.53.17. - Fixes implicit function declaration. Closes: https://bugs.gentoo.org/904392 Closes: https://bugs.gentoo.org/905825 Signed-off-by: Myckel Habets <gentoo-bugs@habets-dobben.nl> Closes: https://github.com/gentoo/gentoo/pull/32201 Signed-off-by: Sam James <sam@gentoo.org> (In reply to Myckel Habets from comment #22) > 2) Stabilize Seamonkey 2.53.17 (maybe fast track?) Sounds good. All done. Could you cleanup the old ebuild and then the eclass? The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9f63d64501b0d4ea9129edede77305dfb034b420 commit 9f63d64501b0d4ea9129edede77305dfb034b420 Author: Myckel Habets <gentoo-bugs@habets-dobben.nl> AuthorDate: 2023-09-08 10:02:12 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2023-09-09 06:59:31 +0000 eclass: remove obsolete python2.7 code from mozcoreconf-v6.eclass Closes: https://bugs.gentoo.org/698980 Signed-off-by: Myckel Habets <gentoo-bugs@habets-dobben.nl> Closes: https://github.com/gentoo/gentoo/pull/32682 Signed-off-by: Joonas Niilola <juippis@gentoo.org> eclass/mozcoreconf-v6.eclass | 7 ------- 1 file changed, 7 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=80bbb8aa79d2564f348c793e88efe1dc940eb935 commit 80bbb8aa79d2564f348c793e88efe1dc940eb935 Author: Myckel Habets <gentoo-bugs@habets-dobben.nl> AuthorDate: 2023-09-08 06:50:08 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2023-09-09 06:59:31 +0000 www-client/seamonkey: cleanup seamonkey-2.53.15-r1 Remove seamonkey-2.53.15-r1 ebuild, because Python 2.7 needs to be removed from portage. Bug: https://bugs.gentoo.org/698980 Signed-off-by: Myckel Habets <gentoo-bugs@habets-dobben.nl> Signed-off-by: Joonas Niilola <juippis@gentoo.org> www-client/seamonkey/Manifest | 3 - www-client/seamonkey/seamonkey-2.53.15-r1.ebuild | 539 ----------------------- 2 files changed, 542 deletions(-) |