Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 698980 - www-client/seamonkey should support Python 3
Summary: www-client/seamonkey should support Python 3
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All All
: Low normal (vote)
Assignee: Myckel Habets
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: py3-tracker, python-3-incompatible
  Show dependency tree
 
Reported: 2019-10-31 03:04 UTC by Arfrever Frehtes Taifersar Arahesis
Modified: 2022-03-22 18:03 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Ogelpre 2021-01-31 09:55:08 UTC
Current stable spidermonkey version 2.53.6 supports py3. Bug can be closed.
Comment 2 Arfrever Frehtes Taifersar Arahesis 2021-01-31 20:51:13 UTC
www-client/seamonkey-2.53.6 through mozcoreconf-v6.eclass depends on dev-lang/python:2.7[ncurses,sqlite,ssl,threads(+)].
Comment 3 Myckel Habets 2022-01-29 13:40:13 UTC
@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?
Comment 4 Joonas Niilola gentoo-dev 2022-01-29 13:54:48 UTC
(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.
Comment 5 Myckel Habets 2022-01-30 10:16:22 UTC
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.
Comment 6 Joonas Niilola gentoo-dev 2022-02-01 16:43:38 UTC
(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.
Comment 7 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-02-01 16:49:13 UTC
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.
Comment 8 Myckel Habets 2022-02-07 11:08:18 UTC
(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.
Comment 9 Myckel Habets 2022-02-07 11:34:54 UTC
Enigmail seems to not support Seamonkey since 2019. I'm considering dropping that from the ebuild.
Comment 10 Joonas Niilola gentoo-dev 2022-02-07 13:25:46 UTC
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?
Comment 11 Joonas Niilola gentoo-dev 2022-02-07 13:35:40 UTC
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.
Comment 12 Myckel Habets 2022-02-23 08:10:12 UTC
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.
Comment 13 Myckel Habets 2022-02-23 08:20:48 UTC
(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.