Dependency Updates

[github-actions]

The content of the target linuxtools-latest.target was updated

Please review the changes and merge if appropriate, or cherry pick individual updates.

The content of the location https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/milestone/latest was updated:

• Unit com.github.jnr.jffi.native was updated from 1.4.0.v20260626-1000 to 1.4.3.v20260916-1000

[akurtakov]

/request-license-review

[github-actions]

/request-license-review

License review requests:

• p2/orbit/p2.eclipse.plugin/com.github.jnr.jffi.native/1.4.3.v20260916-1000

After all reviews have concluded, re-run the license-vetting check from the Github Actions web-interface to update its status.

Workflow run (with attached summary files):
https://github.com/eclipse-linuxtools/org.eclipse.linuxtools/actions/runs/36297457577

[akurtakov]

As this is Orbit content merging to unbreak the build.

[merks]

@akurtakov

I wonder if any thought has been given to expressing the Orbit units using a version range such that they don't need updating for minor version updates?

[akurtakov]

Not really :).

[akurtakov]

After giving it some thought it would actually make master licensecheck verification break unnoticed so until the "duplicate" problem is fixed in dash-licensetool is fixed it's better to be exact to so I can "request" these reviews.

[merks]

I didn't see a comment from Wayne, but I think that is not happening anymore, or it would have happened here.

Of course Orbit does the requests but it is possible that a milestone is produced with a review that's not completed, e.g., h2 for the latest milestone. In that case, the Linux build will remain broken until that review is completed. But maybe that's the goal.

In any case, given the update is automated, and given the update might actually replace a range with an actual version, it's likely not worth the effort...

(I only noticed because the generated reports show me when a target file is modified by the project.)