In T6658#168843, @DataDrake wrote:

Please be patient. I am swamped at work right now and have higher priority issues in Solus to deal with in the little free time I do have, else this would have already been implemented. And please, this isn't debate club. I have laid out the solution that I believe is the best path forward for Java on Solus after almost two years of arguments here and in other communications channels about all of this and more.

In T6658#168822, @akrenz wrote:

Pretty simple really. Each JDK should have its own directory in /usr/lib64.

I think this is the "best" solution. Afterwards one could select his Java version via an extra cmdline tool which creates symlinks for java/javac/jshell/jar. That's how Debian is doing it for update-alternatives (https://linux.die.net/man/8/update-alternatives) or Arch for archlinux-java (https://wiki.archlinux.org/index.php/Java#Package_pre-requisites_to_support_archlinux-java).

For anyone coming here, a workaround is to close and relaunch the software center. Over and over if necessary. I just had do this 6 or 7 times I think. No reboot is necessary.

The issue isn't unstable connections because of the server, it's unstable because of the geographical location of the server hosting the packages compared to your location, and all the hops in between. The connection is much less likely to fail if there are fewer hops. This is the main reason that a CDN exists in the first place, getting the data closer to you for lower latency, higher bandwidth, and fewer hops.

Here is the submitted patch: https://github.com/getsolus/os-installer/pull/2

We know. It's not getting fixed until Fastly is in place

Hi, good to see that it's a known issue. It happened to me on my first install on June 11.
And now it happened on my second install on another computer on another network.

In T2532#150381, @alecbcs wrote:

It looks like the Clear Linux team is no longer interested in integrating this into clr-boot-manager.

Fixed confirmed, thanks :)

I can reproduce on another machine

• OS: Antergos (Arch Linux)
• Java version: 12

This current issue isn't about «Error: Attribution is not loaded yet» => one just have to zoom in and out a bit and tiles load. So lets forget about the Bing issue.

Great that you can reproduce.
Try with another imagery than Bing to see if you get the same rendering issues. Because Bing take few tries to load due to the attribution needing to be loaded first.

can you try launching it with java -jar /usr/share/josm/josm.jar?

Just tested with version 15155 and the issue still percists.
What can I do to investigate?

In T8101#153342, @livingsilver94 wrote:

I'm updating it.

Added in T5874

Thanks @DataDrake I didn't found T6658 :)

Multiple version cohabitation: for a first step, is cohabitation needed from a user (non-dev) point of view?
For example I would like a JRE > 8 to make JOSM (or any app) faster and allow the devs to deprecate JRE 8 sooner and don't be stuck with only the Java features from 5 years ago.

Hi @JoshStrobl , it doesn't seems to be a duplicate of T1216, because the issue is that I don't get to choose the layout so it's defaulted to qwerty. So it is normal that the initramfs gets a qwerty layout.
In the mentioned ticket, they can choose their layout in the installer. While in this case, I can't choose a layout in the installer, that's the issue.