New package: jruby-9.3.8.0

[chloris-pale-green]

Testing the changes

• I tested the changes in this PR: YES

New package

• This new package conforms to the package requirements: YES

Local build testing

• I built this PR locally for my native architecture, (x86_64)
• I built this PR locally for these architectures (if supported. mark crossbuilds):
  • armv6l (crossbuild)

Motivation

The reference Ruby interpreter can not execute threads on multiple CPU cores because of GIL. JRuby is able to perform real threading.

[chloris-pale-green]

All Musl builds seem to be experiencing the same issue:

ERROR: jruby-9.3.7.0_1: file /usr/lib/ruby/gems/shared/specifications/did_you_mean-1.3.0.gemspec has write permission for other users
ERROR: jruby-9.3.7.0_1: post-install_14-fix-permissions: 'find "$PKGDESTDIR" -type f -perm -0002' exited with 1

On my local machine (x86_64), permissions of all the files in the /usr/lib/ruby/gems/shared/specifications directory are 644. Anybody has any idea why post-install_14-fix-permissions seems to fail?

EDIT: Curiously, I was able to cross-build the package for x86_64-musl architecture without errors on my machine. 14-fix-permissions executes successfully. Perhaps the build only fails when building on a Musl architecture natively?

[classabbyamp]

have you tried a native musl build locally? see the instructions for making another masterdir in the readme

[chloris-pale-green]

have you tried a native musl build locally? see the instructions for making another masterdir in the readme

I've installed the x86_64-musl version of Void in a VM and tried building the package. I got the same error as observed here on GitHub. It seems that the file permission issues are Musl-specific.

Consequently, I've added a find command to the template that removes group and other write permissions from all files and directories that happen to have them, if the package is being build on a Musl machine.

I've also changed the way binaries are installed, since I've noticed that one of them did not posses the execute permission. vbin should take care of that (but copies the whole binary rather than a symlink - that's the purpose of the other if clause).

Strangely enough, on a Musl architecture, even with the use of vbin, the binary /usr/bin/irb seems to lack execute permission (644) after installing the package, and I get "permission denied" if I try to run it. The package is still functional, though.

[classabbyamp]

oh you didn't need to go through the trouble of making a whole VM, you can just add another masterdir

[chloris-pale-green]

oh you didn't need to go through the trouble of making a whole VM, you can just add another masterdir

Thank you for the tip. 😊 At first, I went with the method I knew well, but now I've tried the masterdir approach to test x86_64-musl build check error. I have no idea what the error means and I can build the package successfully in x86_64-musl masterdir on my machine.

[chloris-pale-green]

I recommend that the x86_64-musl PR check is re-run. The error seems very random (and does not appear in other Musl architectures), and I am able to build the package in a x86_64-musl VM without any errors.

[chloris-pale-green]

This time it didn't even get to the build part and stopped at Run common/travis/changed_templates.sh:

Your branches is based on too old copy.
Please rebase to newest copy.
Error: Process completed with exit code 1.

I don't understand the error. Is there some Git wizardry I was supposed to do and have not?

[classabbyamp]

if you don't already have it, add this repo as a remote:

$ git remote add upstream https://github.com/void-linux/void-packages.git

then rebase your branch on the upstream master branch:

$ git pull --rebase upstream master

and force-push:

$ git push --force

[chloris-pale-green]

Thank you for your help. 😊 The PR is now in the green.

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.