sbt 1.0.2 has been released. See http://www.scala-sbt.org/download.html
Thank you for the bump request. You can help the maintainer with further information: Does a simple bump [1] work on your system? Chances are high, because a first look on the bump revealed only small changes. [1] https://wiki.gentoo.org/wiki/Custom_repository#Simple_version_bump_of_an_ebuild_in_the_local_overlay
A simple vbump won't work because the ebuild needs: https://dev.gentoo.org/~gienah/snapshots/${P}-src.tar.xz https://dev.gentoo.org/~gienah/snapshots/${P}-ivy2-deps.tar.xz https://dev.gentoo.org/~gienah/snapshots/${P}-sbt-deps.tar.xz and the latest available snapshots there are for 0.13.13.
Created attachment 538734 [details] failed attempt to package sbt 1.2.0 rc1 sbt 1.1.6 and 1.2.0-RC1 hang during src_compile. During the ebuild development I use FEATURES=-network-sandbox to allow it to download lots of stuff during the src_compile, as I know how to disable that by tar'ing up the $(WORKDIR}/{.ivy2,.sbt} directories. The blocking problem is that after it finishes downloading all this stuff, at the point where it is almost ready to start compiling, it forks a second java process and hangs. All attempts to disable the sbt server feature make no difference. downloading https://repo1.maven.org/maven2/org/scala-sbt/ivy/ivy/2.3.0-sbt-b18f59ea3bc914a297bb6f1a4f7fb0ace399e310/ivy-2.3.0-sbt-b18f59ea3bc914a297bb6f1a4f7fb0ace399e310.jar ... [SUCCESSFUL ] org.scala-sbt.ivy#ivy;2.3.0-sbt-b18f59ea3bc914a297bb6f1a4f7fb0ace399e310!ivy.jar (1406ms) :: retrieving :: org.scala-sbt#boot-app confs: [default] 76 artifacts copied, 0 already retrieved (27669kB/147ms) Getting Scala 2.12.6 (for sbt)... :: retrieving :: org.scala-sbt#boot-scala confs: [default] 5 artifacts copied, 0 already retrieved (19632kB/45ms) [info] Loading settings from plugins.sbt ... [info] Loading project definition from /var/tmp/portage/dev-java/sbt-1.2.0_rc1/work/sbt-1.2.0-RC1/project [info] Updating ProjectRef(uri("file:/var/tmp/portage/dev-java/sbt-1.2.0_rc1/work/sbt-1.2.0-RC1/project/"), "sbt-1-2-0-rc1-build")... argus ~ # ps -efl | egrep 'portage.*java' 4 S portage 2116 458 0 90 10 - 1039 do_wai Jul07 pts/11 00:00:00 [dev-java/sbt-1.2.0_rc1] sandbox /usr/lib/portage/python2.7/ebuild.sh compile 0 S portage 2241 2229 0 90 10 - 4673 do_wai Jul07 pts/11 00:00:00 bash /var/tmp/portage/dev-java/sbt-1.2.0_rc1/work/sbt/bin/sbt -d -v -Dsbt.log.noformat=true -Dsbt.server.autostart=false -Dsbtio.path=../io-1.2.0-M2 -Dsbtutil.path=../util-1.2.0-M2 -Dsbtlm.path=../librarymanagement-1.2.0-M3 -Dsbtzinc.path=../zinc-1.2.0-M1 0 S portage 3289 2241 0 90 10 - 1421312 futex_ Jul07 pts/11 00:04:09 java -XX:ReservedCodeCacheSize=128m -XX:MaxMetaspaceSize=256m -Djava.io.tmpdir=/var/tmp/portage/dev-java/sbt-1.2.0_rc1/temp -Duser.home=/var/tmp/portage/dev-java/sbt-1.2.0_rc1/work -Xms2048M -Xmx2048M -Xss2M -jar /var/tmp/portage/dev-java/sbt-1.2.0_rc1/work/sbt/bin/sbt-launch.jar -Dsbt.server.autostart=false -Dsbt.log.noformat=true -Dsbt.server.autostart=false -Dsbtio.path=../io-1.2.0-M2 -Dsbtutil.path=../util-1.2.0-M2 -Dsbtlm.path=../librarymanagement-1.2.0-M3 -Dsbtzinc.path=../zinc-1.2.0-M1 0 S root 8664 24934 0 80 0 - 3301 pipe_w 10:53 pts/31 00:00:00 grep -E --colour=auto portage.*java 1 S portage 18540 3289 0 90 10 - 1421312 do_wai Jul07 pts/11 00:00:00 java -XX:ReservedCodeCacheSize=128m -XX:MaxMetaspaceSize=256m -Djava.io.tmpdir=/var/tmp/portage/dev-java/sbt-1.2.0_rc1/temp -Duser.home=/var/tmp/portage/dev-java/sbt-1.2.0_rc1/work -Xms2048M -Xmx2048M -Xss2M -jar /var/tmp/portage/dev-java/sbt-1.2.0_rc1/work/sbt/bin/sbt-launch.jar -Dsbt.server.autostart=false -Dsbt.log.noformat=true -Dsbt.server.autostart=false -Dsbtio.path=../io-1.2.0-M2 -Dsbtutil.path=../util-1.2.0-M2 -Dsbtlm.path=../librarymanagement-1.2.0-M3 -Dsbtzinc.path=../zinc-1.2.0-M1 argus ~ # I notice that Debian can not figure out how to package sbt either. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873341 SBT is uninstallable; depends on nonexistent packages
In arch linux (community package) there is already sbt-1.3.6 and as I can see is working: https://www.archlinux.org/packages/community/any/sbt/ Looking into pkgbuild file I don't any dependencies complexity: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/sbt https://git.archlinux.org/svntogit/community.git/tree/trunk/sbt.install?h=packages/sbt I have in my personal overlay sbt working, based on arch pkgbuild. [offtopic] When looking forward about know how from other root distros maintainers, I think arch linux is closer to Gentoo, and so a better reference. Unfortunately is not as good as Gentoo, since Gentoo profile concept and all tooling are incomparable. Mark Wright, not meant badly about Debian, they really have additional dependencies problems that are related to the distro workflow than with the original source.
This problem is blocking building all dev-java/sbt 1.x versions from the source code up to and including 1.3.6. (In reply to Samuel Bernardo from comment #4) > I have in my personal overlay sbt working, based on arch pkgbuild. The arch pkgbuild is providing the binary, its not trying to build sbt from the source code, so I assume the ebuild in your personal overlay is like dev-java/sbt-bin.
(In reply to Mark Wright from comment #5) > In reply to Samuel Bernardo from comment #4) > > I have in my personal overlay sbt working, based on arch pkgbuild. > > The arch pkgbuild is providing the binary, its not trying to build sbt from > the source code, so I assume the ebuild in your personal overlay is like > dev-java/sbt-bin. The ebuild I adapted by default have binary use flag enabled. But if disabled will get the sources from git directly: https://cgit.gentoo.org/repo/user/ssnb.git/tree/dev-java/sbt/sbt-1.3.6.ebuild I need to get back into my overlay and update the ebuilds to current EAPI, but I hope to do it during next month. I know that doesn't follow the Gentoo ebuild development good practices to disable network-sandbox, but is possible to have sbt compiled from source without that restriction. It makes completely sense that in the gentoo main tree this kind of ebuilds should be avoided, but from another overlays that can be bypassed. This is required because is becoming a common practice with many languages to have their own dependencies manager that loads lot of code outside reference source base. As an example you have that behavior happening in almost recent programming languages.
