Upgrade server to Ubuntu 20.04.1 LTS

[Don-vip]

New release '20.04.1 LTS' available.

I guess we should upgrade. The new release still provides openjdk-8 and 11, so I see no particular risk.

[stoecker]

What's the idea of using LTS when we anyway update each time? :-)

Risk: Trac

• I don't want to use the recent trac version 1.4.2, but keep the somwhat older 1.2.2.
• If they finish a new version with python 3 support I think we can update again

[Don-vip]

There's no rush, I guess we have until 2023 to update :) ​https://ubuntu.com/about/release-cycle
We can wait for a new version of Trac to make the upgrade more meaningful.

[taylor.smock]

Ubuntu 22.04 was just released (also, we need to update the debian/ubuntu repo).

Anyway, it looks like Ubuntu 22.04 has Java 8, 11, and 17.

From comment:1:

Risk: Trac

• Most recent stable version is 1.4.3, Ubuntu 22.04 appears to still have a python2 package.
• Ubuntu 22.04 has trac 1.5.3 in their package repository.

From ​https://trac.edgewall.org/ticket/13333#comment:18, there may be a 1.6 release in time for Debian 12. I don't know if I would count on it though.

[taylor.smock]

We've got ~4 months before EOL for 18.04. Is there anything I can do to help?

[taylor.smock]

Ping: ~1.5 months until EOL. See ​https://ubuntu.com/blog/18-04-end-of-standard-support .

[stoecker]

Replying to taylor.smock:

We've got ~4 months before EOL for 18.04. Is there anything I can do to help?

Well the update itself is easy. It's only when something goes wrong...

[stoecker]

BTW. Is it possible to upgrade 18 directly to 22? I usually use openSUSE and there it's possible (with some caution).

[taylor.smock]

I think it might be technically possible, but the ​supported upgrade paths don't have that as an option. So, for our purposes, no, we should not upgrade directly from 18.04 to 22.04.

As far as comment:1 goes (risks), we are still running Trac 1.2.2, so we would have to update to 1.5.x. I was just looking into what version of Trac was in Ubuntu 20.04, and apparently it was not in their repos. I was hoping that 1.4.x was there, just to have a stepping point if something failed when doing the upgrade to 22.04 with Trac 1.5.x.

This upgrade (while necessary) looks like a PITA.

[stoecker]

As long as python2.7 is still available we can keep Trac (I'm planning to update another instance to current devel as no new release is in sight - when that works maybe that's an option for josm also).

[taylor.smock]

It looks like python2 is still available in Ubuntu 22.04 (I tested with podman run -it --rm ubuntu:22.04 /bin/bash -c "apt update && apt install -y python2 && python2 --version").

I'm not seeing a virtual env package though.

[stoecker]

See Announcement

[stoecker]

Hmm. No 22.04 yet. Upgrade to 20.04 was troublesome enough. Please report any issues.

[anonymous]

Please report any issues.

https://josm.openstreetmap.de/wiki/Help/Styles/MapCSSImplementation

It's full of error messages as of this weekend ;)

[skyper]

Yes, some processors do not work like #!mapcss and #!rule:

*[highway] {
}

Additionally, I think the individual style for highlighting set in user preferences is not working or is a problem with #!preset.

[stoecker]

MapCSS style fixed.

[skyper]

Thanks for the upgrade, by the way.

Replying to stoecker:

MapCSS style fixed.

Thanks, highlighting works again, too.

[taylor.smock]

Replying to stoecker:

Hmm. No 22.04 yet. Upgrade to 20.04 was troublesome enough. Please report any issues.

Will do. I was more worried about running an EOL OS than about getting to the latest and greatest. We don't have to worry about upgrading for another two years, and hopefully upgrading to 22.04 and then to 24.04 will be easier (I'm going to hope that Trac 1.6 is actually released).

Anyway, thanks for working on the OS upgrade.

[stoecker]

Yes. Major problem is python2 caused by the missing Trac release using python3.

[stoecker]

Maybe if somebody else than me asks them for a new Trac release? ;-)

[taylor.smock]

I somehow don't think that will get them on-Trac...

On a different note, I think they might actually be doing something soon. At least one of the tickets that they indicated was a blocker for 1.6.0 has had its milestone set to 1.6.1 (see ​https://trac.edgewall.org/ticket/13406) and they have GitHub CI up and running.

There are also indications on one of their ​mailing lists that there is some work towards releasing 1.6.0 (from February of this year).

[taylor.smock]

It looks like something got borked with the test renders. See r18707 (patch, nothing related to MapCSS) and run 7973/jdk=JDK8.

I hacked around the openjdk limitation on macOS, and a visual compare seems to have the text for the right blue path in GroB Vahlberger StraBe. I don't know if that is what the problem is though.

EDIT: See #12025 for where the failing test comes from. It looks like it isn't just the test environment, so something caused a regression somewhere (see #7841 for original "flying text" issue on macOS, probably a different issue on the server).

[taylor.smock]

The failing test (https://josm.openstreetmap.de/jenkins/job/JOSM/jdk=JDK8/lastCompletedBuild/testReport/org.openstreetmap.josm.gui.mappaint/MapCSSRendererTest/testRender_TestConfig__String__14_/) looks like it is a very small difference in the diacritics. I'll commit the files generated with r18706. There do not appear to be any differences between 22.10 and 20.04 for this test (I compared the failures on the 22.04 machine against the failures on CI).

[taylor.smock]

In 18717/josm:

See #19912: Upgrade server to Ubuntu 20.04

Upgrade test reference images to match the images generated post-upgrade.
The images were generated with r18706 (the last passing CI build).

[taylor.smock]

It looks like something is going on with the plugin repo (source:osm). It isn't updating with some commits. I haven't checked to see if the dist folder works yet (I'll be running a dist since I updated the i18n).

[stoecker]

Replying to taylor.smock:

It looks like something is going on with the plugin repo (source:osm). It isn't updating with some commits. I haven't checked to see if the dist folder works yet (I'll be running a dist since I updated the i18n).

Fixed (NOTE: It wasn't the repo, but the trac sync).

[taylor.smock]

Fixed (NOTE: It wasn't the repo, but the trac sync).

Thanks. I'm sorry I have to keep bugging you. :(

Anyway, I noticed another problem source:trunk/src/org/openstreetmap/josm/gui/MapFrame.java?annotate=blame​

Warning: Can't use blame annotator:

svn blame failed on trunk/src/org/openstreetmap/josm/gui/MapFrame.java: 200019 - Version mismatch in 'svn_fs' (expecting equality): found 1.13.0, expected 1.14.2
200019 - Version mismatch in 'svn_repos' (expecting equality): found 1.13.0, expected 1.14.2
200019 - Version mismatch in 'svn_delta' (expecting equality): found 1.13.0, expected 1.14.2
200019 - Version mismatch in 'svn_subr' (expecting equality): found 1.13.0, expected 1.14.2

I'm going to guess that the svn that was installed in 18.04 was either from a PPA or compiled locally.

[stoecker]

Reason is simple. As I don't get python2 bindings for 1.14.2 I made them for 1.13.0. That works everywhere else, but seems in this case somehow the 1.14.2 and 1.13.0 libraries get mixed.

[stoecker]

Hope it works now.

[taylor.smock]

Looks like it. Thanks.

[taylor.smock]

I don't know if the reason why the last two builds failed was due to me, or due to a server change. I didn't change anything related to the creation of the REVISION.XML file, so I'm thinking something in the server environment.

The message from the logs is:

create-revision:
[xmlproperty] [Fatal Error] REVISION.XML:1:1: Content is not allowed in prolog.

[stoecker]

Aaah. Now parts of the remaining 1.13.0 install tests infected the system SVN. Hopefully I cleaned that as well. I really miss my usually toolchain from openSUSE when working under Ubuntu. :-(

[taylor.smock]

It looks like the JOSM-Performance job is having the same issue.

With that said, I honestly don't know if the JOSM-Performance job is still useful -- when I was looking at some of the perf code, it looked like there was supposed to be a graph showing timings in Jenkins (Measurement Plots is what was referenced).

[stoecker]

Probably affected all svn operations :-) Only report svn related errors beginning with data from now on...