Merge ~vpa1977/ubuntu/+source/visualvm:2.1.6upgrade into ubuntu/+source/visualvm:ubuntu/devel

I have tried to add more openjdk versions to the launcher patch, but visualvm itself crashes with security manager exception when running under openjdk-20. I have left launcher patch unchanged.

Basic testing:

Package install:

---------------------------cut-----------------------
apt install visualvm
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  visualvm
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 4202 kB of archives.
After this operation, 21.8 MB of additional disk space will be used.
Get:1 https://ppa.launchpadcontent.net/vpa1977/visualvm/ubuntu mantic/main amd64 visualvm all 2.1.6~us1-0ubuntu1~ppa3 [4202 kB]
Fetched 4202 kB in 13s (332 kB/s)
Selecting previously unselected package visualvm.
(Reading database ... 34879 files and directories currently installed.)
Preparing to unpack .../visualvm_2.1.6~us1-0ubuntu1~ppa3_all.deb ...
Unpacking visualvm (2.1.6~us1-0ubuntu1~ppa3) ...
Setting up visualvm (2.1.6~us1-0ubuntu1~ppa3) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
------------------------------------------cut----------

Package removal:
------------------------------------------cut----------
apt remove visualvm
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  adwaita-icon-theme alsa-topology-conf alsa-ucm-conf ant ant-optional antlr3 at-spi2-common at-spi2-core ca-certificates-java dconf-gsettings-backend dconf-service default-jdk default-jdk-headless default-jre default-jre-headless
  fontconfig fontconfig-config fonts-dejavu-core fonts-dejavu-extra gsettings-desktop-schemas gtk-update-icon-cache hicolor-icon-theme humanity-icon-theme java-common javahelp2 junit4 libantlr-java libantlr3-runtime-java
  libapache-pom-java libasm-java libasound2 libasound2-data libatk-bridge2.0-0 libatk-wrapper-java libatk-wrapper-java-jni libatk1.0-0 libatspi2.0-0 libavahi-client3 libavahi-common-data libavahi-common3 libbsh-java
  libcairo-gobject2 libcairo2 libcommons-codec-java libcommons-io-java libcommons-logging-java libcommons-parent-java libcups2 libdatrie1 libdconf1 libdeflate0 libdrm-amdgpu1 libdrm-common libdrm-intel1 libdrm-nouveau2
  libdrm-radeon1 libdrm2 libequinox-osgi-java libfelix-framework-java libfelix-main-java libfontconfig1 libfontenc1 libfreetype6 libgail-common libgail18 libgdk-pixbuf-2.0-0 libgdk-pixbuf2.0-bin libgdk-pixbuf2.0-common libgif7
  libgl1 libgl1-amber-dri libgl1-mesa-dri libglapi-mesa libglvnd0 libglx-mesa0 libglx0 libgraphite2-3 libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libhamcrest-java libharfbuzz0b libice-dev libice6 libjbig0 libjcommander-java
  libjna-java libjna-jni libjna-platform-java libjpeg-turbo8 libjpeg8 libjson-simple-java libjsr305-java liblcms2-2 liblerc4 libllvm15 libnb-org-openide-modules-java libnb-org-openide-util-java libnb-org-openide-util-lookup-java
  libnb-platform18-java libnspr4 libnss3 libosgi-annotation-java libosgi-compendium-java libosgi-core-java libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 libpciacce...

Looks largely fine, but the version number in the changelog looks wrong?

> Looks largely fine, but the version number in the changelog looks wrong?
Since we are uploading the package before Debian, we need to make sure that the original tarball can be replaced by the Debian version, hence ~us1 suffix to indicate the Ubuntu-specific repack.
This was suggested some time ago when I made a mistake with openjdk original tarball, e.g. see[1]

[1] https://launchpad.net/ubuntu/+source/openjdk-17/+publishinghistory

checked re-downloading original tarball with uscan - no differences introduced by the repack, so removed the suffix.

>> Looks largely fine, but the version number in the changelog looks wrong?
> Since we are uploading the package before Debian, we need to make sure that the original tarball can be replaced by the Debian version, hence ~us1 suffix to indicate the Ubuntu-specific repack.
> This was suggested some time ago when I made a mistake with openjdk original tarball, e.g. see[1]

Ah, that makes sense, thanks for the explanation! Thanks for checking uscan produces the same output -- that gives us more confidence we're likely to be uploading what Debian will be in future. Still, the ~us1 suffix makes a lot of sense to me now, and it's better to be safe than sorry so I'll strip the top commit off here, and upload with that suffix in place. Just in case!