"This release should be used instead of 3.0.1. This release fixes
several issues." - http://scons.org/scons-301-is-available.html
More than 90% of the 346 rebuilds succeed without any problems (I've
tested it against aeff3080d0). As far as I
can tell most of the problematic packages either failed before the
upgrade or for a reason that is unrelated to this SCons update. But it
is possible that this'll cause a few regressions, I'll try to watch out
for build failures on Hydra.
The attribute sconsPackages.scons_3_0_0 is still available in case this
breaks anything.
There are separate derivations for these libraries and we don't want
conflict. Multitarget is generally more useful, and will eventually
speed up cross builds, so why not?!
One should depend on
- `stdenv.cc.bintools`: for executables at build time
- `libbfd` or `libiberty`: for those libraries
- `targetPackages.cc.bintools`: for exectuables at *run* time
- `binutils`: only for specifically GNU Binutils's executables, regardless of
the host platform, at run time.
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
We are patching g-ir-scanner to produce absolute paths in the GIR
files. When an application uses an internal library placed in a
non-standard path (e.g. $out/lib/gnome-shell), the scanner needs
to be informed. For autotools-based apps, the full path was
obtained from libtool-wrapped files; with Meson, this is no longer
possible – we need to pass the path information in some other way.
This commit channels the --fallback-library-path option added
to g-ir-scanner in aforementioned patch.
Main change: glibc: 2.25-x -> 2.26-y, containing security fixes,
and various features and deprecations. Unfortunately, some of the
latter still cause (transitively) a couple hundred newly failing jobs.
I'm not delaying anymore, so that we have the security fix on master.
I mainly patched gcc, llvm and icu, but I can't fix everything...
- I can see some regressions, especially due to fetchzip rename c3255fe8ec.
- Darwin is only half-rebuilt on Hydra ATM.
- But there quite a few security fixes within.
The biggest benefit is that we no longer have to update the registry
package. This means that just about any cargo package can be built by
nix. No longer does `cargo update` need to be feared because it will
update to packages newer then what is available in nixpkgs.
Instead of fetching the cargo registry this bundles all the source code
into a "vendor/" folder.
This also uses the new --frozen and --locked flags which is nice.
Currently cargo-vendor only provides binaries for Linux and
macOS 64-bit. This can be solved by building it for the other
architectures and uploading it somewhere (like the NixOS cache).
This also has the downside that it requires a change to everyone's deps
hash. And if the old one is used because it was cached it will fail to
build as it will attempt to use the old version. For this reason the
attribute has been renamed to `cargoSha256`.
Authors:
* Kevin Cox <kevincox@kevincox.ca>
* Jörg Thalheim <Mic92@users.noreply.github.com>
* zimbatm <zimbatm@zimbatm.com>
- gcc not needed at all as dependency
- other D compilers can be used instead of dmd, so it's not good to use it as a runtime dependency.
- Adding checkPhase (disabled for now because network access is limited in sandbox mode)
- Improve package description.
"SCons release 3.0.0 now available from the download page at
SourceForge. This release should be used instead of 2.5.1. This release
fixes several issues. TThis will be the first release to support Python
versions earlier than 2.7 as well as 3.5+."
"NOTE: This is a major release. You should expect that some targets may
rebuild when upgrading. Significant changes in some python action
signatures. Also switching between PY 2.7 and PY 3.5, 3.6 will cause
rebuilds."
* Skip verifying checksums for already fetched packages.
Needed for two-staged building in Nix:
1. Build a fixed derivation with `bazel fetch` (filtered out of non-reproducable bits).
2. Build an actual derivation which uses fetched dependencies (skipping
checksums needed here because they depend on the build directory).
* Don't clean environment variables for children processes.
Needed for Nix compiler wrappers.
Pew was actually broken, due to a SHELL PATH check that had been added
in the previous release (though this shouldn't have hampered users with
bash as their shell)
