FS#72953 - [josm] new runtime flags required
Attached to Project:
Community Packages
Opened by lnnz (lnnz) - Wednesday, 08 December 2021, 17:11 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:03 GMT
Opened by lnnz (lnnz) - Wednesday, 08 December 2021, 17:11 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:03 GMT
|
Details
Description:
The josm package has new runtime flags required by the upstream developers. These are only required for some functionality, and the lack of them does not make the package unusable. Additional info: * package version(s): 18303-1 * config and/or log files etc. * link to upstream bug report, if any: https://josm.openstreetmap.de/ticket/21649 Steps to reproduce: * open josm * open history on a way * press Help * bug report window appears and Help window does not load |
This task depends upon
Closed by Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:03 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/josm/issues/1
Saturday, 25 November 2023, 20:03 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/josm/issues/1
--add-opens=java.desktop/javax.swing.text.html=ALL-UNNAMED
See https://josm.openstreetmap.de/ticket/21989 .
See also https://josm.openstreetmap.de/browser/josm/trunk/native/linux/tested/usr/bin/josm for a known good start script (Debian).
Also, adding `install -Dm755 $pkgname/native/linux/tested/usr/bin/josm "${pkgdir}"/usr/bin/josm` should remove the need for https://github.com/archlinux/svntogit-community/blob/packages/josm/trunk/PKGBUILD#L43-L56 (and the need to try to manually work around differences in Java versions).
thanks a lot for helping us out!
I've tried your fixes and I get the error:
Error: Unable to access jarfile /usr/share/josm/josm.jar
The file does not exist, the correct path seems to be:
/usr/share/java/josm/josm.jar
Does this need to get fixed in josm or our package? What is your suggestion?
@jlichtblau Would it be okay for you, if I co-maintain the package? Where do you get the changelog from and why is it even in our svn? Is it important?
The script reads environment variables, so setting `JOSM_PATH=/usr/share/java/josm/josm.jar` in the environment (or in `/etc/default/josm`, sourced via `. "/etc/default/${JOSM_VERSION}"`) should work.
The path to JOSM is set with `JOSM_PATH="${JOSM_PATH:-/usr/share/${JOSM_VERSION}/${JOSM_VERSION}.jar}"`
The other env setting of interest might be for javafx, `JAVAFX_HOME="${JAVAFX_HOME:-/usr/share/openjfx/lib}"`.
I tried to make the script as configurable as possible for downstream users when I was fiddling with it a few months back.
Anyway, if the attached patch is applied, JOSM will start and run properly.
@Taylor: Why do we need to set the JOSM_PATH via sed in the startup script. Isnt adding it in the config better? That sounds more correct to me, however it does not work at all. I guess the reason is, that previously this config was loaded with the custom startup script. Doesnt it make sense to keep it?
```
[ -f /etc/conf.d/josm ] && . /etc/conf.d/josm
```
With your other fix I get the error at startup:
ls: cannot access '/usr/lib/jvm/default-runtime/lib/javafx*.jar': No such file or directory
This turns out, because the sed command is not written correct and the newline will expand. This is what the script contains:
```
JAVAFX_HOME="$(ls /usr/lib/jvm/default-runtime/lib/javafx*.jar | tr "
" ":" | sed 's/.$//')"
```
If I remove that, no error will occur. So is this "hack" even needed???
You have also added java-openjfx as a new dependency. Is that required? For me josm also starts without that dependency.
I'm not a disto packager, but I would think that it would be better to have sane defaults, in case the user deletes the config file.
> With your other fix I get the error at startup:
That is funny. It worked for me when I tested. Does `/usr/lib/jvm/default-runtime/lib/` exist? The only reason for the `JAVAFX_HOME="$(ls [...])"` was because I couldn't just set the `JAVAFX_HOME` variable to the directory; there were some issues with double loading modules.
> If I remove that, no error will occur. So is this "hack" even needed???
JavaFX is _not_ required by JOSM itself. Plugins may require JavaFX. Of note, there is the `javafx` plugin which pretty much just adds an audio player and some utility classes, and then Microsoft Streetside which uses JavaFX for cubemapping 360 images.
> You have also added java-openjfx as a new dependency. Is that required? For me josm also starts without that dependency.
So the answer is _technically_ no, it is not required for base functionality, but it is required for some plugins.
```
Using /usr/bin/java to execute josm.
Error occurred during initialization of boot layer
java.lang.module.FindException: Module javafx.web not found
```
It works if I uncomment the last sed line in the PKGBUILD (the newline is expanded, but this works regardless.)
The error (`ls: cannot access '/usr/lib/jvm/default-runtime/lib/javafx*.jar': No such file or directory`) is caused by the failing glob. One can simplify that to a simple echo (as the glob does the expansion on itself), paired with `shopt -s noglob` there will only be an empty string if there are no matching files.
Thus
sed -i '5 aJAVAFX_HOME="$(shopt -s nullglob && echo /usr/lib/jvm/default-runtime/lib/javafx*.jar | tr " " ":")"' "${pkgdir}/usr/bin/josm"
in the PKGBUILD works also but should not generate an error (and fall back to the default in the start script, but I do not know if that causes any problems)
Maybe java-openjfx should at least be added to optdepends?
@taylor.smock
Why did you comment that line?
sed -i 's/--module-path ${JAVAFX_HOME} //' "${pkgdir}/usr/bin/josm"
@malteger thanks for that fix!
I've updated the package once more with those fixes. I will try to update the version itself now.