Package Details: metals 1.3.5-1

Git Clone URL: https://aur.archlinux.org/metals.git (read-only, click to copy)
Package Base: metals
Description: Language Server For Scala
Upstream URL: https://scalameta.org/metals/
Keywords: jvm lsp scala
Licenses: Apache-2.0
Submitter: isomarcte
Maintainer: isomarcte
Last Packager: isomarcte
Votes: 10
Popularity: 0.122162
First Submitted: 2019-04-10 17:11 (UTC)
Last Updated: 2024-10-03 15:29 (UTC)

Dependencies (8)

Required by (0)

Sources (8)

Latest Comments

1 2 3 Next › Last »

gonsolo commented on 2024-09-18 06:23 (UTC)

A patch for updating to 1.3.5 and adding nvchecker for easy updating: https://gist.github.com/gonsolo/d360da64e987e56f39df34e962da43fd

isomarcte commented on 2024-05-13 12:40 (UTC)

Hey @Coelacanthus, I saw your orphan request. I didn't respond because I had no context on what RFC 16 was. Normally when I see RFC I think the IETF RFCs, and I assumed "M.I.T. is now to receive all Network Working Group memos." didn't apply (https://www.rfc-editor.org/rfc/rfc16.txt).

Thank you for the link in your orphan request, now that I see what you are referring to, I'll happily update this license string.

Coelacanthus commented on 2024-01-16 15:54 (UTC)

Please follow RFC16 use Apache-2.0

shilka commented on 2023-04-30 14:05 (UTC)

@isomarcte Sorry for my late reply. I've tried extra-x86_64-build for convenience. It's work now. Thanks for your suggestion.

isomarcte commented on 2023-04-06 14:36 (UTC)

@shilka I just forced the build to run using JDK 11 in a clean chroot and I'm unable to reproduce this issue. Both yay and makepkg do not run in a clean chroot, which is usually fine, but can mean that the build result will be affected by your system setup. That error looks like the output one gets when running graalvm against a class compiled with a JRE target version not supported by graalvm. Are you using graalvm on your system?

Also, can you try to build the package with the extra-x86_64-build command from the devtools package? This will build the package in a clean chroot and remove any configuration on your system as a possible cause. (see: https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot)

shilka commented on 2023-04-06 06:41 (UTC)

@isomarcte Yes, the building process terminated with errors pointed to the version problem. I use yay to manage all pkgs. But for the buggy aur pkg, I turned to makepkg to reproduce the problem.

isomarcte commented on 2023-04-03 16:31 (UTC)

@shilka, I don't follow. Are you saying this package is failing to build for you?

Can you tell me how you are trying to build it? Manually with makepkg?

shilka commented on 2023-03-28 02:24 (UTC)

I'm currently use java-11-openjdk, but makepkg reports many errors, which start with: [error] java.lang.IllegalArgumentException: error: release version 8 not supported

It seems that the installer mismatched the java version.

jypma commented on 2021-11-19 12:16 (UTC)

Bumping the version to 0.10.9 installs the new version just fine. Just remember to also bump version-fix.patch. I wonder if we can make PKGBUILD inject the version number into there, so there's not two places to edit? I completely overlooked that first, making for a mysteriously non-working install :-)

isomarcte commented on 2020-09-24 02:35 (UTC)

@das_kube I'm unable to reproduce this on 0.9.3-1. Can you try building it with extra-x86_64-build from the devtools package and see if you still have issues? That builds it in a systemd-nspawn container which dramatically reduces the likelihood that anything on the build system (your system, in this case) will effect the build.

1 2 3 Next › Last »