This does not remove any prior versions: LibreSSL versions are
maintained for a year after their corresponding OpenBSD branch is tagged
for release:
- v2.6.x, part of OpenBSD 6.2-release, Nov 2017 (EOL: Nov 2018)
- v2.7.x, part of OpenBSD 6.3-release, Apr 2018 (EOL: Apr 2019)
- v2.8.x, expected OpenBSD 6.4-release, ETA Sep 2018 (EOL: Sep 2019)
This also does not change the default version: the stable branch remains
2.7.x, and 2.8.0 is the newest released development version. 2.8 can
become the default after OpenBSD-6.4
Closes#44760 (as it's redundant).
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The user who wrote this code on GitHub has since deleted their account,
making any updates impossible. Furthermore, this package is redundant
anyway: Zstandard has been shipping a compatible 'zstdmt' binary, API,
and stable multi-threading support for over a year now.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This puts the debug information in a separate output, as expected. This allows
meaningful symbol names to appear in DWARF-based tools like perf and gdb.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
See #22653 or #38469. 'manveru' reported this on IRC again, but unfortunately a
real fix requires a bit more work. In the mean time, this plugs the leak with a
bit of duct tape.
'timescale' is an often desired extension and, in the mean time, this
workaround means you also do not have to install something like postgis (with a
large dependency set) into your closure to get things to work.
Ideally in the mean time, *all* postgresql extensions should have $out/bin
created for them... Doing this will require more ongoing work, or a proper
fix to the buildEnv nonsense going on.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The Z3 source code is effectively compiled into two completely separate
objects: the z3 binary file, and the libz3.so library -- but the binary is not
linked against the shared library, it simply incorporates all of the object
files. The Z3 code base results in an ~25MB object on x86_64-linux. As a
result, splitting bin/ and lib/ results in a 50% reduction in closure size.
(The include/ directory is also surprisingly large at .5MB...)
This also splits the python API into a completely separate .python attribute,
as well.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This requires a bit of fiddling with the ldflags patches and reworking a few
things about how the SCM info is configured. Ideally, not much more will change
before the 6.0 release, I think...
This also upgrades all FoundationDB packages to use the ordinary libressl
expression (which is now at 2.7.x), and changes around a few other things,
which will require a rebuild.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This requires a bit of fiddling with the ldflags patches and reworking a few
things about how the SCM info is configured. Ideally, not much more will change
before the 6.0 release, I think...
This also upgrades all FoundationDB packages to use the ordinary libressl
expression (which is now at 2.7.x), and changes around a few other things,
which will require a rebuild.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
OPAE is a software toolchain and for integration and use of programmable
accelerators, currently supporting Intel Arria 10 and Stratix 10 FPGAs.
This package only contains the userspace software SDK tools and C
libraries -- not the OPAE Linux drivers.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Without explicitly specifying that libsasl2 is part of the build, and
without explicitly making it part of pylibmc's linker flags for its
CPython extension, the cpython code enters a build state error where it
instead attempts to blindly `dlopen("libsasl2.so")` out of
$LD_LIBRARY_PATH; this fails as it can't be found in the store,
obviously.
The bigger problem with this is that it otherwise makes pylibmc
unusable, as it will try to immediately load libsasl2 at startup. This
means even using 'import pylibmc' at all will cause a failure.
Instead, add cyrus_sasl into the build closure of the library, and pass
an argument to the setup.py script to properly pass -lsasl2 to the C
extension. This causes a link to properly be formed.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
We need base-compat-0.10 for 8.4, but the older version wanted 0.9.
(Criterion 1.4.1.0 now uses base-compat-batteries-0.10, in fact)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Otherwise, the test suite fails, due to the 'Lambdas' test failing:
Lambdas: FAIL (1.06s)
42c42
< foo8 x = (\ Foo a _ -> a) x
---
> foo8 x = (\ (Foo a _) -> a) x
I assume this is a minor bogus failure due to some change in 8.4.3 that
nobody expected.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This obsoletes two of the included patches, one of them RISC-V specific,
since they've been picked up by upstream.
This build has been confirmed as being able to build and run an (extremely
recent) RISC-V Fedora 28 Rawhide image, available from:
https://fedorapeople.org/groups/risc-v/disk-images/
Signed-off-by: Austin Seipp <aseipp@pobox.com>
JDK 7 was technically EOL'd a while ago, although RedHat etc are still
doing updates I believe. However, JDK 8 is the default in the tree and
really used everywhere, and JDK 7 isn't seeing many updates by current maintainers, so dropping it seems appropriate.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Nobody has stepped up to keep maintaining this and it's several
years old, and the last strict Java 7 dependency, as it won't work
with newer versions without an update.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This is the only package that still needs ECJ and has no dependencies.
It's ancient and unmaintained and should just be removed.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
./bin/java now apparently requires zlib.so, otherwise the whole
thing is busted. This is even required in the minimal configuration.
Unfortunately this impiles a rebuild of *all* OpenJDK packages and
their downstream dependencies.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Apparently, async mode for libftdi 0.20 is allegedly disabled when using
libusb-compat wrappers, as libftdi does not really support libftdi 1.x. Because
we only ship libusb-compat, this would normally make async mode completely
unavailable.
Except distributions like Ubuntu just disable this check completely! See this
patch from Launchpad:
https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/libftdi/trusty/view/head:/debian/patches/04_async_mode.diff
In the spirit of good competition (and feature parity for software that
*doesn't* support the synchronous mode, thanks to Ubuntu silently ensuring
their async-only paths work) we enable this just the same.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
In the long run it looks like we may actually need a small set of patches to
Perf if that's more maintainable, in which case we would much rather check
NIX_DEBUG_INFO_DIRS.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Austin Seipp