JavaFX is an optional component of Java since version 11, not used by
most applications and also a source of many security issues (i.e.: it
bundles both media codecs and WebKit). Also, it is only available in
some platforms.
So this commit will disable JavaFX by default, that will allow us to
reduce the closure size significantly and reduce the attack surface of
Java applications for most users. Derivations that needs it can always
override the parameter themselves.
JavaFX is an optional component of Java since version 11, not used by
most applications and also a source of many security issues (i.e.: it
bundles both media codecs and WebKit). Also, it is only available in
some platforms.
So this commit will disable JavaFX by default, that will allow us to
reduce the closure size significantly and reduce the attack surface of
Java applications for most users. Derivations that needs it can always
override the parameter themselves.
JavaFX is an optional component of Java since version 11, not used by
most applications and also a source of many security issues (i.e.: it
bundles both media codecs and WebKit). Also, it is only available in
some platforms.
So this commit will disable JavaFX by default, that will allow us to
reduce the closure size significantly and reduce the attack surface of
Java applications for most users. Derivations that needs it can always
override the parameter themselves.
JavaFX is an optional component of Java since version 11, not used by
most applications and also a source of many security issues (i.e.: it
bundles both media codecs and WebKit). Also, it is only available in
some platforms.
So this commit will disable JavaFX by default, that will allow us to
reduce the closure size significantly and reduce the attack surface of
Java applications for most users. Derivations that needs it can always
override the parameter themselves.
JavaFX is an optional component of Java since version 11, not used by
most applications and also a source of many security issues (i.e.: it
bundles both media codecs and WebKit). Also, it is only available in
some platforms.
So this commit will disable JavaFX by default, that will allow us to
reduce the closure size significantly and reduce the attack surface of
Java applications for most users. Derivations that needs it can always
override the parameter themselves.
Since #200337 gobject-introspection propagates itself via
depsTargetTargetPropagated, so one doesn't have to add it to every
derivation twice. The problem is that gobject-introspection still is in
a lot of buildInputs and will thus propagate itself again for target,
breaking evaluation unnecessarily if gobject-introspection doesn't
evaluate on whatever the target platform turns out to be.
temurin-bin and openjdk19 caused such a situation via gtk3 which GHC's
JavaScript backend depends on. To fix evaluation of those packages in
pkgsCross.ghcjs.buildPackages, we'll just disable the features pulling
in gtk3 until this is fixed properly.
Co-authored-by: Robin Gloster <mail@glob.in>
stdenv: print message if structuredAttrs is enabled
stdenv: add _append
reduces the chance of a user doing it wrong
fix nix develop issue
output hooks don't work yet in nix develop though
making $outputs be the same on non-structuredAttrs and structuredAttrs
is too much trouble.
lets instead make a function that gets the output names
reading environment file '/nix/store/2x7m69a2sm2kh0r6v0q5s9z1dh41m4xf-xz-5.2.5-env-bin'
nix: src/nix/develop.cc:299: std::string Common::makeRcScript(nix::ref<nix::Store>, const BuildEnvironment&, const Path&): Assertion `outputs != buildEnvironment.vars.end()' failed.
use a function to get all output names instead of using $outputs
copy env functionality from https://github.com/NixOS/nixpkgs/pull/76732/commits
as usual this is mostly copy-pasted from 18, so this commit is best
reviewed with '--find-copies-harder'
stop exposing openjdk 18 since it was not a long-term support release
change the default openjdk from 17 to 19 since nixpkgs is a
rolling-release repository
drop the ceremony around bootstrapping via adoptopenjdk for 64-bit
builds vs. via earlier openjdk builds for 32-bit, because, to be
frank, since we're using temurin now, it's not a simple copy-paste
job. :-/ if someone needs a 32-bit openjdk, that work can be done
separately.
JavaFX revs from 17 to 19; it looks like 18 was never packaged along
with JDK 18.
* the gradle invocation used to build JavaFX must still be done with
Java 18, as gradle does not yet support running itself on Java 19.
* a couple of patches need to be applied, since a new State enum was
introduced in the JDK that collides with one in JavaFX.
* the hash of the gradle dependencies has not changed, which is
surprising, but as far as I can tell correct.
One application (libreoffice) doesn't work with 19 yet, so pin it to
jdk 17 for now.
Co-authored-by: Mario Rodas <marsam@users.noreply.github.com>
openjfx17's plugins/av/mpegtsdemuxer.c expects ffmpeg 4 and does not build
with ffmpeg 5.1.1.
This change does not result in any rebuilds because nixpkgs `ffmpeg` still
points to `ffmpeg_4`.
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: gsttypefindelement.o:(.bss._gst_disable_registry_cache+0x0): multiple definition of
`_gst_disable_registry_cache'; gst.o:(.bss._gst_disable_registry_cache+0x0): first defined here
openjfx17 is not affected.
This commit adds entries to the Rosetta Stones in
adoptopenjdk-bin/generate-sources.py and compilers/openjdk/8.nix, and
runs adoptopenjdk-bin/generate-sources.py to regenerate
adoptopenjdk-bin/sources.json.
With this commit, `nix-build . -A jdk8_headless` succeeds on
powerpc64le. Headless jdk is used as part of the build process for
many packages so this opens up access to them.
The current build attempts to fetch
https://cdn.azul.com/zulu/bin/zulu17.30.19-ca-jdk17.0.1-macosx_aarch64.tar.gz
on aarch64-darwin, and that URL does not exist.
Changing the Zulu version to 17.30.19 to 17.30.15 fixes the URL, and
the hash requires no changes, indicating that the hash must have
originally been computed for version 17.30.15 anyway.
Note: this change does not make build sequential. Build system still
uses it's way to parallelize the build.
The only effect of this change is not to pass unsupported -j option
to Makefile when nixpkgs default will be switched to
enableParallelBuilding = true;
Remove -Werror=implicit-function-declaration, which when passed to cmake
for webkit build breaks C++ compiler configuration due to spurious warnings:
`cc1plus: warning: '-Werror=' argument '-Werror=implicit-function-declaration' is not valid for C++`
This patch fixes https://github.com/NixOS/nixpkgs/issues/103493 for JDK8
only.
I'm upstreaming only for JDK8 to get quorum on the approach and then
adding the patches to the remaining versions.
Improved JDK8 patch
Improved JDK8 patch
Manipulating the store paths on the Nix side doesn’t work with CA
derivations (because these paths are just placeholders of the form
`/{hash}` at eval-time)
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
Some applications, like the Jetbrains IDEs, check for a suffix to
determine if a stable JDK is used.
This flag was already passed for older versions, but it got lost for
OpenJDK 14+.
* update two explicit references to jdk14 to just jdk, which no longer
points at jdk8 after #89731.
* patch an explicit -XX:+UseConcMarkSweepGC to -XX:UseG1GC, as the
former now throws an error (after having been deprecated since jdk 9)
The removes the "-internal" suffix from the OpenJDK version string.
Some applications, like the Jetbrains IDEs, check for a suffix to
determine if a stable JDK is used.
Thanks to @liff for the hint in #92837!
After making `ffmpeg` point to the latest `ffmpeg_4`, all packages that
used `ffmpeg` without requiring a specific version now use ffmpeg_3
explicitly so they shouldn't change.
* some configure options have been removed upstream
* need a new patch to deal with gcc format warnings
11 remains, as it is an LTS release; all existing users of 11 in
nixpkgs remain on 11 for now.
openjdk/default.nix and openjdk/darwin/default.nix become the
expressions for the current version (12 now; later 13, 14, etc.).
(note: darwin/default.nix was unreferenced; the new version is derived
from darwin/11.nix.)
