Check Arch Linux installer works before release

[jvican]

As we're getting ready for the release, I'd like to make sure there are no breakages with our existing installation methods. @TheElectronWill Could you check that running sbt install produces a valid Arch Linux package that you can install in your box? I can't do that because I no longer own an Arch Linux box.

[TheElectronWill]

Yes I can!

sbt install fails with (bloopgun / Graalvm-native-image / packageBin) java.io.IOException: Cannot run program "native-image" (...) no such file or directory

So I've run sbt createLocalArchPackage instead to have something to check.

I first ran into issue coursier/coursier#1613, which is fixed by using the latest coursier version (RC6-13) but it's not available in AUR yet. I've made a PR for that.

After updating coursier, the pkg built and installed. But bloop isn't installed correctly: .bloop.aux is missing from the package so nothing works :slightly_frowning_face:
EDIT: it looks like this isn't the only problem. I've added this line to the PKGBUILD

install -Dm755 .bloop.aux "$pkgdir"/usr/lib/bloop/.bloop.aux

but running

• bloop fails with /usr/bin/.bloop.aux: no such file or directory (seems like cd dirname $0 isn't enough, because of the symlink)
• /usr/lib/bloop fails with Could not load or find main class bloop.bloopgun.Bloopgun. I guess this is because of the missing bloopgun native image which should have been generated by sbt install?

[jvican]

Thanks a lot for looking into this!

I don't fully understand why those issues are happening but let me share some context that might explain some of the changes in the new installer: from v1.4.0 on, bloop has changed its installation method and it now only installs bloopgun (our new CLI that compiles to GraalVM Native). Bloopgun is installed by coursier and the resulting binary will make sure the server is running in the background.

So, in this respect, we no longer have symlinks nor the previous installation structure, now we only install a binary in /usr/bin/bloop and that's it. Could the issues you're running into be caused because your previous installation is living together with the new installation?

[jvican]

Friendly ping @TheElectronWill :smile: There's an open PR adding 1.4.0 release notes and would like to release as soon as we figure this one out. Tried to set up a vagrant environment in macOS with Arch Linux but that failed, so any help to figure out if the coursier fix is the only one required would be great!

[TheElectronWill]

Could the issues you're running into be caused because your previous installation is living together with the new installation?

Unfortunately no, I've got the same results when I first uninstall bloop completely.

I'll try to fix things and report back to you ASAP :smiley:

[TheElectronWill]

First problem fixed by installing graalvm and graalvm-native-image (of course! should have thought of that earlier...). But 8 gigs of RAM don't seem to be enough to complete the building of the native image so I can't test any further :slightly_frowning_face:

we no longer have symlinks nor the previous installation structure, now we only install a binary in /usr/bin/bloop and that's it.

The current PKGBUILD creates a folder /usr/lib/bloop, then a link to the executable within it. If we don't need the folder anymore (I see that .jvmopts should now go into $HOME/.bloop/.jvmopts or in bloop.json) it should be removed.

[jvican]

I'll remove the creation of the /usr/lib/bloop folder as well as the symlink, thanks!

Keep in mind that you should not be compiling to GraalVM during the installation process, we compile to GraalVM native in CI/CD during the install step that generates all of the formulas and binaries. Could you try the installation doing sbt install instead of sbt createLocalArchPackage?

[TheElectronWill]

Keep in mind that you should not be compiling to GraalVM during the installation process, we compile to GraalVM native in CI/CD during the install step that generates all of the formulas and binaries.

Yes, it's the install task that fails (more precisely, bloopgun/graalvm-native-image:packageBin). The rest doesn't consume that much memory (fortunately) :smile:

[TheElectronWill]

PR #1284 should make the package work again! Sorry I couldn't fully test it before the release.

[marcin-rzeznicki]

@TheElectronWill You mention in the PR that the use of systemd service was questionable. It's an interesting note - using a service manager to run a service seems to be a very logical choice. Care to elaborate?