The point where this broke is likely when llvmPackages_11.stdenv started
respecting stdenv.hostPlatform.linker and thus using GNU binutils'
ld.bfd for linking. That linker can't deal with clang's C++ ABI.
To fix this we introduce a modified version of llvmPackages_11.stdenv
which uses llvmPackages_11.bintools for linking purposes (I also aim to
upstream this in some form, but am not sure about the details atm, so
we'll just do this in the tvl overlay for now). This is the precondition
for getting our C++ packages in //third_party to work
again. Additionally the following fixes were necessary:
* abseil-cpp needed to be updated (by overriding the version from
nixpkgs for now, since I can't update the subtree on my own) to
fulfill grpc's requirements (grpc 1.41.0 needs abseil-cpp LTS
20210324).
* gtest needs a patch from nixpkgs which fixes the path to its include
directory for CMake.
* We need to build re2 with clang as well, otherwise linking will fail.
Fixes b/132.
Change-Id: I7b64579fe96451547babe070fd35db398581e49d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3701
Tested-by: BuildkiteCI
Reviewed-by: lukegb <lukegb@tvl.fyi>
Reviewed-by: tazjin <mail@tazj.in>
... instead of the one from the overlay, which can be out of sync.
This requires the TVL overlay to be applied after the Emacs overlay.
Change-Id: Idac403ea612e334c14b45759dc216699a506678f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3484
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: tazjin <mail@tazj.in>
The backported fix is no longer required and we can just apply the
patch in the overlay, this makes everything a little easier.
Change-Id: I654a1bb002eef5c578b8e576e133a159bde3f850
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3483
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Adds ECL as a second supported implementation, specifically a statically
linked ECL. This is interesting because we can create statically linked
binaries, but has a few drawbacks which doesn't make it generally
useful:
* Loading things is very slow: The statically linked ECL only has byte
compilation available, so when we do load things or use the REPL it is
significantly worse than with e. g. SBCL.
* We can't load shared objects via the FFI since ECL's dffi is not
available when linked statically. This means that as it stands, we
can't build a statically linked //web/panettone for example.
Since ECL is quite slow anyways, I think these drawbacks are worth it
since the biggest reason for using ECL would be to get a statically
linked binary. If we change our minds, it shouldn't be too hard to
provide ecl-static and ecl-dynamic as separate implementations.
ECL is LGPL and some libraries it uses as part of its runtime are as
well. I've outlined in the ecl-static overlay why this should be of no
concern in the context of depot even though we are statically linking.
Currently everything is building except projects that are using cffi to
load shared libaries which have gotten an appropriate
`badImplementations` entry. To get the rest building the following
changes were made:
* Anywhere a dependency on UIOP is expressed as `bundled "uiop"` we now
use `bundled "asdf"` for all implementations except SBCL. From my
testing, SBCL seems to be the only implementation to support using
`(require 'uiop)` to only load the UIOP package. Where both a
dependency on ASDF and UIOP exists, we just delete the UIOP one.
`(require 'asdf)` always causes UIOP to be available.
* Where appropriate only conditionally compile SBCL-specific code and
if any build the corresponding files for ECL.
* //lisp/klatre: Use the standard condition parse-error for all
implementations except SBCL in try-parse-integer.
* //3p/lisp/ironclad: disable SBCL assembly optimization hack for all
other platforms as it may interfere with compilation.
* //3p/lisp/trivial-mimes: prevent call to asdf function by substituting
it out of the source since it always errors out in ECL and we hardcode
the correct path elsewhere anyways.
As it stands ECL still suffers from a very weird problem which happens
when compiling postmodern and moptilities:
https://gitlab.com/embeddable-common-lisp/ecl/-/issues/651
Change-Id: I0285924f92ac154126b4c42145073c3fb33702ed
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3297
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: eta <tvl@eta.st>
Maybe this one will include a fixed telega.el?
Change-Id: I0de2dafdc8e5b82ed1174e83023cd96fab5f190e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3300
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
I used //tools/depot-nixpkgs-update for this - thanks again, sterni!
Included fixes:
* temporary workaround for building notmuch python package, fixed in
upstream already (but channel hasn't advanced there)
* Disable fprintd in grfn.system.yeren, as the fprintd-tod package
currently has a version mismatch in nixpkgs
Co-authored-by: Griffin Smith <grfn@gws.fyi>
Change-Id: If6d71b08ace9db57daadfe3b69b9cd4aec6a5a4e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3274
Reviewed-by: grfn <grfn@gws.fyi>
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
* 3p/buzz: bump to latest master (1.6.0)
* 3p/emacs/explain-pause-mode: adjust to package-build update
MELPA's package build now cares about git revisions, but calling VC
commands in a nix build is usually a bad idea. Thus upstream nixpkgs
passes `$commit` to the `buildPhase` and otherwise fails with an
error message that doesn't really point to the issue. Upstream change:
9140d4b06f
* 3p/overlays/emacs: udpate to 2021-07-25 to support the package-build
update. Without this emacsPackages.xelb (for tazjin's exwm) would fail.
Change-Id: I7cd782fe7d66ed4ea78c529b79fe761d921f46a8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3253
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: grfn <grfn@gws.fyi>
Includes the following depot changes & fixes:
* stable moves to NixOS 21.05
* stable isn't used anymore (but we'll keep the mechanism)
* haskell overlay's `random` override is removed (YAY!)
* grfn/iso: Switch to regular kernel rather than
latest kernel, as latest kernel is currently marked as broken due to zfs
* grfn/home: Use julia_16-bin temporarily
julia 1.5 (current julia-stable, source built release in nixpkgs)
doesn't pass its own test suite. Julia 1.6 doesn't have a source built
package in nixpkgs yet, so julia_16-bin appears to be the only working
julia derivation currently.
* tazjin/tverskoy: Use zfs unstable, as stable zfs doesn't work with the
latest kernel
Co-Authored-By: Griffin Smith <grfn@gws.fyi>
Co-Authored-By: sterni <sternenseemann@systemli.org>
Change-Id: I6f2e3d9f75077e4755de6bde9104d44b584cbe4c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3174
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: grfn <grfn@gws.fyi>
* users/grfn/system/home/yeren: remove obsolete awscli2 overrides
* ops: make new isSystemUser || isNormalUser assertion happy
* users/grfn/system/system/mugwump: make buildkite agents system users
* users/tazjin/nixos/camden: set isSystemUser = true for git
* users/tazjin/emacs: Remove missing & broken packages
* third_party/openldap: remove, as the argon2 module is now enabled upstream
* third_party/gerrit_plugins: Pinned new unstable hashes
* third_party/nix, third_party/grpc: Disabled CI as these are broken
* third_party/overlays/emacs: Bumped version to stay in sync with channel
* third_party/buzz: Update LIBCLANG_PATH to reference libclang.lib,
since libclang's default output no longer contains libclang.so
* users/grfn/system/home: Install julia-stable instead of julia (which
aliases to julia-lts), as the latter depends on an insecure version of
libgit
Change-Id: Iff33b0ecb0ef07a82d1de35e23c40d2f4bf0f8ed
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3001
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: grfn <grfn@gws.fyi>
* This was mostly for //third_party/nix and its dependencies which now
have been set to use llvmPackages_11 manually.
* For //users/grfn/achilles we also manually select the newer LLVM version.
* //tools/cheddar doesn't seem to need llvm anymore.
* //third_party/buzz also compiles with clang 7.1.0
* replace clang-tools everywhere with new attribute clang-tools_11
For the future we may want to have something similar again, but it may
not be necessary to invest too much time into it: nixpkgs is set to
upgrade their default llvmPackages to LLVM 11 as well at some point in
the near future.
Co-Authored-By: sterni <sternenseemann@systemli.org>
Change-Id: Id83868dbc476a6c776b59518b856c933f30ea79d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3135
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: grfn <grfn@gws.fyi>
Adds all TVL Emacs packages to the emacsPackages fixpoint unter
`tvlPackages` ... one step closer to native compilation.
Change-Id: I938689ccab057164babfb88cd467a490b3efd39b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3004
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Reviewed-by: adisbladis <adisbladis@gmail.com>
This adds adisbladis' Emacs overlay, which makes bleeding-edge
functionality such as native compilation of Elisp available.
Change-Id: I29861cb4da37bf8bf7fdb6fba5f2525c7a024356
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3002
Reviewed-by: adisbladis <adisbladis@gmail.com>
Tested-by: BuildkiteCI
sbcl 2.0.9 introduced a new warning:
> minor incompatible change: the compiler signals a warning at
> compile-time when an initform of T, NIL or 0 does not match
> a STANDARD-CLASS slot's declared type.
This broke a few packages, but they all have been fixed upstream in the
meantime and we only need to bump their versions. The culprits are:
* defclass-std which possibly has become unmaintained since the fix
(december 2020).
* cl-prevalence which also needs one symbol from bt now
* lisp-binary which also includes a new file now
Change-Id: I06bb47a129d5ef912a623315c1281aedd1ceac2a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2934
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: glittershark <grfn@gws.fyi>
Fixes included:
* exposed gtest in the package set, required for protobuf
* pinned SBCL to version 2.0.8: The channel moved it to >2.1, and a
bunch of warnings seemed to be killing our builds - we should
investigate this later.
* removed kernel patches from //users/tazjin/frog: this machine is
currently out of service anyways, not worth fixing while it's offline
* removed steam & lutris from frog (they're currently broken)
* removed Haskell overrides for hedgehog-classes & hgeometry-combinatorial
* use gRPC sources from upstream and inject Abseil via Nix instead
* fix for renamed grpc import in //third_party/nix
* use libfprint-tod from upstream nixpkgs in glittershark/yeren and
delete glittershark/pkgs/fprintd entirely, since all of the patches used
there are available and working from upstream now (and stopped working
here after the bump)
Change-Id: Ia90e6f774f7b88bc9e60d28351b900ca43ee2695
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2901
Reviewed-by: glittershark <grfn@gws.fyi>
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: lukegb <lukegb@tvl.fyi>
Tested-by: BuildkiteCI
The random_1_2_0 attribute of haskellPackages currently holds random
1.2.0 which is what we want to have. We need to disable tests because
they cause an infinite recursion as basically all testing libraries
depend on random. This has the nice side effect that we no longer need
import from derivation for random 1.2.0 (but owothia and xanthous still
use it).
Re-enable CI for xanthous.
Additinonally we need to deal with the fallout of the haskellPackages
overlay now also being pulled in for some machines since cl/2910 and
let pandoc compile with random 1.2.0.
Change-Id: I78d220e5bd35f3469d80d69e77e712a529f21d33
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2924
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: glittershark <grfn@gws.fyi>
Please read b/108 to make sense of this.
This gets rid of the explicit list of exposed packages from nixpkgs,
and instead makes the entire package set available at
`third_party.nixpkgs`.
To accommodate this, a LOT of things have to be very slightly shuffled
around. Some of this was done in already submitted CLs, but this
change is unfortunately still quite noisy.
Pay extra attention to:
* overlay-like functionality that was partially moved to actual
overlays (partially as in, the minimum required to get a green
build)
* modified uses of the package set path, esp. in NixOS systems
Special notes:
* xanthous has been disabled in CI because of issues with the Haskell
overlay
* //third_party/nix has been disabled because of other unclear
dependency issues
Both of these will be tackled in a followup CL.
Change-Id: I2f9c60a4d275fdb5209264be0addfd7e06c53118
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2910
Reviewed-by: glittershark <grfn@gws.fyi>
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
nixpkgs_exposed is going away, and the haskell overlay is independent
from that.
See also b/108, cl/2910
Change-Id: I3aea6dfc427a914f3f88146fd0b45d60dfd45a1a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2918
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
