openjfx{11,17,21,22}: pin to FFmpeg 6 #331522
Conversation
Not “drop”; these files are literally not referenced anywhere in the tree, as far as I can tell.
These have all been end‐of‐life for more than 10 months.
Seems to start up fine for me with the default JRE, and the package couldn’t be easily used before this anyway as version 20 has reached end of life. It does complain about what a big mistake we’re making by not passing Shenandoah GC flags to the JVM on start‐up, but I doubt that has anything to do with the JRE bump, and it lets you click through.
These have all been end‐of‐life for more than 10 months.
emilazy
requested review from
thiagokokada,
jlesquembre,
chayleaf and
Infinidoge
emilazy
force-pushed
the
push-qwqwnrwsktks
branch
from
3a6f628 to
2dc6ced
Compare
|
(I initially had a bunch of confused stuff in the original post because I didn’t realize how far back the FFmpeg 5 patch had been backported. Fixed now.) |
|
My suggestion is to just disable ffmpeg for older versions and see if someone complains about them. From my experience nobody cares too much about OpenJfx, but if there is someone that comes and complains we have two alternatives:
|
emilazy
force-pushed
the
push-qwqwnrwsktks
branch
from
2dc6ced to
164f9ea
Compare
|
It was really easy to backport the FFmpeg 6 patch to OpenJFX 11 and 17, given that upstream already did the hard work for the FFmpeg 5 one, so I just did that. I have no idea if it’s actually necessary or not, but it should put to rest any potential concerns. I might not be so merciful when the time comes to drop FFmpeg 6, though :) I’m running the builds again now but this should be good to go after #331514 is merged. Though, of course, it would be good if someone could try to actually run some JavaFX thing and see how it goes. |
|
The builds went fine. |
Description of changes
Part of my campaign to get rid of FFmpeg 4. This is stacked on top of #331514, so please ignore all but the last commit.
This is completely untested. The builds go through successfully on
x86_64-linuxandaarch64-darwin, and the upstream compatibility fixes are pretty trivial, but I suspect that OpenJFX might be doing runtime dynamic library loading stuff that could mask problems. There are two relevant upstream PRs here:These have both been merged; FFmpeg 5 support was backported to OpenJFX ≥ 11 and FFmpeg 6 support to OpenJFX ≥ 20. I have backported the trivial FFmpeg 6 to 11 and 17 myself, although I’m not sure if it was actually necessary since they built fine without it. (I do get build failures for all of these versions when trying to use FFmpeg 7, so they’re not completely agnostic to the package they’re being supplied, but then I’m unsure what those version lines are doing.)
I have no real idea how to go about testing these changes – what uses OpenJFX anyway, and what would exercise the FFmpeg‐related parts of it? – so suggestions and help with that would be very useful.
Result of
nixpkgs-reviewrun on x86_64-linux 11 package failed to build:
24 packages built:
Result of
nixpkgs-reviewrun on aarch64-linux 117 packages built:
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.