Apparently this does not depend on stdenv's macOS SDK at all,
and carries around its own go-specific toolchain. So this works
fine as-is and doesn't need any changes in Nixpkgs to support a
10.13 deployment target.
This allows the Go compiler in nixpkgs (eg. buildGoModule) to work with
crossSystem.config == mips-*, eg mips-unknown-linux-musl, and
succesfully generate Go MIPS binaries.
nix-build -A grpcurl --arg crossSystem '{ config = "mips-unknown-linux-musl"; }'
This unfortunately cannot currently be tested on qemu-mips as Go emits
ELF files that fail to execute correctly in qemu-user (see:
https://go-review.googlesource.com/c/go/+/239217, on track to land in Go
1.17). However, I have tested this on a physical MIPS device.
I have not been able to build anything using cgo (hit various
compilation errors in C dependencies), but considering
mips-unknown-linux-musl is not a support nixpkgs target this isn't that
surprising.
Because:
* `go-bootstrap` is a native build input of go, so it needs to have
an offset of -1. Otherwise, e.g. when building a go cross-compiler,
it will try to make go-bootstrap a cross-compiler too.
* have to specify `buildPackages` for the `stdenv` override, otherwise
`buildPackages.stdenv` will be the same as `pkgs.gcc8Stdenv`.
Changes are minor - I ended up just patching the ssl certs at the root
file, rather than trying to keep up with the various darwin changes.
The externalnetwork test helper location changed, to so I had to update
that patch as well.
- Add xcbuild as propagatedBuildInput on darwin 7e25bdba5e
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.
This is used in https://github.com/tweag/gomod2nix to reconstruct a
vendor metadata file.
With the vendor checks we need a lot more metadata which isn't
relevant for building packages, especially since we've already locked
the dependency graph ahead of time
This has been ported from FreeBSD: https://reviews.freebsd.org/D24122
The compiler does not need it anymore, has not needed it for many years
iirc. This just goes in and pollutes the environment overriding the
users GOPATH and causing grief.
Go even warns about it itself, without vs with this commit:
```sh
~> go env GOPATH
/home/manny/go
~> nix-shell -p go
~> go env GOPATH
warning: GOPATH set to GOROOT (/nix/store/gvw1mfpdrk7i82884yhxf9lf5j3c12zm-go-1.14.1/share/go) has no effect
/nix/store/gvw1mfpdrk7i82884yhxf9lf5j3c12zm-go-1.14.1/share/go
~> exit
~> nix-shell -I nixpkgs=cloned/NixOS/nixpkgs -p go
~> go env GOPATH
/home/manny/go
~> exit
```
* 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
Prepend the nix path to the zoneinfo.zip file and keep the original alternatives
to allow go programs built using nix to run on non nix servers.
see https://github.com/NixOS/nixpkgs/issues/54603
In our tests we have experienced failures of this test,
but it was otherwise not reproducible so far. A backported
upstream fix did not alleviate the issue either, so disabling
seems workable for now.
`pkgsBuildTarget` allows us to avoid repeated and confusing conditions.
The others merely provide clarity for one the foreign package set's
target platform matters.
fetchFromGitHub and thus fetchzip hashes the contents of the archive and
not the archive itself. Unicode file names lead to different checksums
on HFS+ vs. other file systems because of Unicode normalisation
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
https://groups.google.com/forum/#!msg/golang-announce/mVeX35iXuSw/Flp8FX7QEAAJ
We have just released Go 1.11.5 and Go 1.10.8 to address a recently reported security issue. We recommend that all users update to one of these releases (if you’re not sure which, choose Go 1.11.5).
This DoS vulnerability in the crypto/elliptic implementations of the P-521 and P-384 elliptic curves may let an attacker craft inputs that consume excessive amounts of CPU.
These inputs might be delivered via TLS handshakes, X.509 certificates, JWT tokens, ECDH shares or ECDSA signatures. In some cases, if an ECDH private key is reused more than once, the attack can also lead to key recovery.
The issue is CVE-2019-6486 and Go issue golang.org/issue/29903. See the Go issue for more details.
He prefers to contribute to his own nixpkgs fork triton.
Since he is still marked as maintainer in many packages
this leaves the wrong impression he still maintains those.
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/go/versions.
These checks were done:
- built on NixOS
- Warning: no invocation of /nix/store/sz746n0jm0n8dnv47d7cqvwny8ncfbi4-go-1.10.3/bin/gofmt had a zero exit code or showed the expected version
- /nix/store/sz746n0jm0n8dnv47d7cqvwny8ncfbi4-go-1.10.3/bin/.go-wrapped passed the binary check.
- /nix/store/sz746n0jm0n8dnv47d7cqvwny8ncfbi4-go-1.10.3/bin/go passed the binary check.
- 2 of 3 passed binary check by having a zero exit code.
- 0 of 3 passed binary check by having the new version present in output.
- found 1.10.3 with grep in /nix/store/sz746n0jm0n8dnv47d7cqvwny8ncfbi4-go-1.10.3
- directory tree listing: https://gist.github.com/499abd38cfb9318ba6bbcd885951c6b8
- du listing: https://gist.github.com/04fbe15eac23c814fa6b313c8e543e4c
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/go/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/w2wgdl5ljbx1fq6iwlavrl4nzbchq954-go-1.10.2/bin/.go-wrapped help’ got 0 exit code
- ran ‘/nix/store/w2wgdl5ljbx1fq6iwlavrl4nzbchq954-go-1.10.2/bin/go help’ got 0 exit code
- found 1.10.2 with grep in /nix/store/w2wgdl5ljbx1fq6iwlavrl4nzbchq954-go-1.10.2
- directory tree listing: https://gist.github.com/249bfa4dc4d10281576f20de902e501a
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
