Bug 242014 - www/jetty8: jettyctl fails to run with Python 3: SyntaxError: invalid token
Summary: www/jetty8: jettyctl fails to run with Python 3: SyntaxError: invalid token
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Jimmy Olgeni
URL:
Keywords: needs-patch, needs-qa
: 242015 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-11-17 00:34 UTC by Martin Waschbüsch
Modified: 2023-12-02 13:12 UTC (History)
5 users (show)

See Also:
olgeni: maintainer-feedback+
koobs: merge-quarterly?


Attachments
proposed patch: use the upstream start/stop script (7.29 KB, patch)
2019-11-17 11:14 UTC, Martin Waschbüsch
martin: maintainer-approval? (olgeni)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Waschbüsch 2019-11-17 00:34:12 UTC
www/jetty8 comes with a control script (/usr/local/sbin/jettyctl) written in python.
The package Makefile does not seem to depend on a specific version of python,
but said control script makes use of python2 syntax.

When trying to start jetty, I get:

Starting jetty.
  File "/usr/local/sbin/jettyctl", line 83
    executable = stat.S_IMODE(finfo) & 0111
                                          ^
SyntaxError: invalid token
/usr/local/etc/rc.d/jetty: WARNING: failed to start jetty

I do not know much python, but in python3 leading zeros are no longer accepted, so I guess an octal bitmask for file permissions would need to be written as 0o0111.

However, while doing so will fix the particular error message, the script still does not work.

Upstream, there is a shell script for starting and stopping jetty. Maybe that would be a better approach? If, as may well be, this control script is the only reason why jetty needs to pull in python as a dependency, using a shell script instead sounds like a reasonable thing to do?
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2019-11-17 01:01:01 UTC
*** Bug 242015 has been marked as a duplicate of this bug. ***
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2019-11-17 01:05:10 UTC
- Is jettyctl FreeBSD authored/provided, or upstream provided?
- Does upstream claim/document support for Python 3?
- Can we find references that say only Python 2.x is currently supported?
- Are there any upstream bug reports, PR's or commits that add Python 3 support?
Comment 3 Martin Waschbüsch 2019-11-17 07:43:32 UTC
(In reply to Kubilay Kocak from comment #2)

jettyctl is provided by the FreeBSD package as www/jetty8/files/jettyctl.in.

I could not find any reference to jettyctl in the upstream tarball:
https://repo1.maven.org/maven2/org/eclipse/jetty/jetty-distribution/8.1.15.v20140411/jetty-distribution-8.1.15.v20140411.tar.gz
(nor does the tarball contain the string 'python' anywhere :D)

Indeed, jetty9 no longer has a python based script in FreeBSD either, but patches the upstream-provided jetty.sh.

I will try to adapt that and see if I can come up with a patch to the package to make it work the same way as jetty9.
Comment 4 Martin Waschbüsch 2019-11-17 11:14:35 UTC
Created attachment 209203 [details]
proposed patch: use the upstream start/stop script

I am unsure if there are other things in the Makefile that should be adjusted,
but with this patch, jetty8 will use the upstream start/stop script.
poudriere testport worked without problems (tested on a 12.1-RELEASE jail), as did starting and stopping jetty.
Comment 5 Daniel Engberg freebsd_committer freebsd_triage 2021-10-04 23:47:11 UTC
Hi Jimmy,

Any progress on this one?
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2021-10-05 00:21:37 UTC
Is removing USES=python correct if it needs Python at runtime for the control script?

Does it only support a particular subset of Python versions? Does USES=python need a :<version-spec>?

If it's only required at runtime, ',run' may be required. However, if the script produces .pyc/pyo files upon first invocation, the files should be run through Pythons standard 'compileall' function to produce and package these, otherwise the resulting files will be orphaned on the system on deinstall.

Note also that any scripts invoking Python should invoke (shebang) using the specific version of Python the port has been built with, or uses, using either:

  - PYTHON_CMD, or 
  - LOCALBASE/sbin/foo-{PYTHON_VER} (with an additional LOCALBASE/sbin/foo version pointing to it). See USE_PYTHON=concurrent

We should also match upstream's documentation with respect to what the name of the script is (with or without .sh extension)
Comment 7 Rene Ladan freebsd_committer freebsd_triage 2023-12-02 13:12:49 UTC
No activity in over two years, EOL upstream for almost ten years, and this port expired today.