Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 698980

Summary: www-client/seamonkey should support Python 3
Product: Gentoo Linux Reporter: Arfrever Frehtes Taifersar Arahesis <arfrever.fta>
Component: Current packagesAssignee: 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    

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.
Comment 14 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2022-08-10 07:19:06 UTC
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.
Comment 15 Myckel Habets 2022-08-10 09:41:38 UTC
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.
Comment 16 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2022-08-10 09:48:52 UTC
Thanks.  Please keep us posted.
Comment 17 Myckel Habets 2022-09-22 09:03:59 UTC
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.
Comment 18 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2023-04-27 13:28:50 UTC
Anything new to report?  FWICS .15 still requires py2.7.
Comment 19 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-04-27 13:30:30 UTC
https://bugs.gentoo.org/904392#c2
Comment 20 Myckel Habets 2023-04-29 12:04:08 UTC
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.
Comment 21 Myckel Habets 2023-05-29 07:36:49 UTC
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.
Comment 22 Myckel Habets 2023-08-05 09:45:01 UTC
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
Comment 23 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-08-07 04:20:00 UTC
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>
Comment 24 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-08-07 04:20:11 UTC
(In reply to Myckel Habets from comment #22)
> 2) Stabilize Seamonkey 2.53.17 (maybe fast track?)

Sounds good.
Comment 25 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-09-02 17:13:52 UTC
All done. Could you cleanup the old ebuild and then the eclass?
Comment 26 Larry the Git Cow gentoo-dev 2023-09-09 06:59:48 UTC
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(-)