Use proper Qt bindings (#65399). Note, current version didn't work for
me, new version does.
The libfive library is licensed under MPL 2.0, while the libfive-guile
and libfive-studio are under GPL 2+
Superseeds #66128
Everything is copied as-is from 9 (except version and hash).
Some platform-specific patches might not apply anymore;
I'm lazily leaving that for the community to fix.
* mari0: init at 1.6.2
* Quote URL per RFC 45, use SSL
Co-authored-by: Ryan Mulligan <ryan@ryantm.com>
* Inherit pname and version instead of setting name explicitly
Co-authored-by: Ryan Mulligan <ryan@ryantm.com>
Co-authored-by: Ryan Mulligan <ryan@ryantm.com>
This is needed by newer versions of `tensorflow` and other ML tools, so we
should start working on an upgrade of the default versoin in the distribution.
the -small packages depend on all hydra buildable dependencies
the non-small ones depend on packages3d which exceeds hydra's limit
set platforms to all (kicad is cross-platform)
clarify package differences in the description
set maintainers on just the top level derivation
switch -unstable to not save debug symbols
indicate patch in version string
note broken dependencies
Linux provides some tools to interact with the gpiochip interface (which
replaces the deprecated sysfs GPIO interface). Expose these as a
package.
The tool has not changed much recently, so there is no need to package a
version for each kernel.
Since the introduction of php.unwrapped there's no real need for the
phpXXbase attributes, so let's remove them to lessen potential
confusion and clutter. Also update the docs to make it clear how to
get hold of an unwrapped PHP if needed.
* treewide Drop unneeded go 1.12 overrides
* Fix packr to be go module compatible.
I updated to version 2.8.0 which is the latest on master.
Then due to the 2 different sets of go modules which are used, I split
the build into two different derivations, then merged them togethor
using symlinkJoin to have the same output structure as the existing derivation.
* Remove consul dependency on go1.12
I updated the consul version to 1.7.2 and flipped it to building using
modules.
* Remove go1.12 from perkeep.
Update the version to the latest unstable on master.
* Update scaleway-cli to not be pinned to go1.12
Switched the version to 1.20
* Update prometheus-varnish-exporter to not depend on go1.12
* Update lnd to build with go1.12
Updated the version
Forced only building subpackages with main to prevent panics over
multiple modules in one repo
* Remove go1.12 from openshift
Had to update the version to 4.1.0 and do a bit of munging to get this
to work
* Remove go1.12 completely.
These are no longer needed.
* Update bazel-watcher and make it build with go 1.14
This includes several enhancements in the underlying compiler, including
codegen improvements for AVX-512, Ice Lake CPU definitions,
cross-{arch,os} compilation (currently unsupported due to multilib
issues), and more.
This also bumps the LLVM backend to the 10.0 release. Note that ispc
itself requires a few extra stability patches on top of 10.0 for AVX-512
support, but these aren't applied for us. Therefore AVX-512 still has
some extra, rough edges.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The package was marked as broken for 3 years, there were no
upstream updates for 8 years, and the program requires third
party services that don't provide APIs to work. I think it's
safe to say that this program is not going to work.
This implements the override pattern for builds done with buildEnv, so
that we can, for example, write
php.override { fpmSupport = false; }
and get a PHP package with the default extensions enabled, but PHP
compiled without fpm support.
This will avoid breaking the build whenever a non-major kernel update
happens. In the update script, we map each kernel version to the latest
patch for the latest kernel version less than or equal to what we
have packaged.
Previously, callPackage would try and fill the arguments such as `name`
and `src` which would cause problems if those existed as top-level
attributes. This also makes it clearer what part is the function
signature.
Then document the derivation inline in the code to explain the ellipsis
and various use-cases.