Question:
, CVSSv3=9.8 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives.
merged - closing

{ stdenv, fetchurl, gettext, bzip2 }: stdenv.mkDerivation rec { <del> name = "sysstat-12.2.0"; </del> <ins> name = "sysstat-12.2.3"; </ins> src = fetchurl { url = "http://pagesperso-orange.fr/sebastien.godard/${name}.tar.xz"; <del> sha256 = "0xc3983ccr0dwab1px2jhbgj86pfmmr29k7ggnwjwm1qigmriak1"; </del> <ins> sha256 = "0c7lcjj796fvb0abqlhkval82r9yp5kvn3vi9k823r45422xv5y1"; </ins> }; buildInputs = [ gettext ];


Question:
Describe the bug The package is supposed to vend a binary called . Instead it's vending a binary called . The upstream repo has a Makefile that explicitly passes to . I don't see any equivalent in our package (which bypasses the Makefile). This is a problem both because of breaking expectations, and also because the package makes the assumption that provides a binary called . In particular, the script tries to invoke the binary as part of the subcommand. To Reproduce Steps to reproduce the behavior: what binaries it provides Expected behavior It should provide . Notify maintainers Also the maintainers, in case the resolution is to change to use the name instead of : Metadata system: host os: multi-user?: sandbox: version: channels(lilyball): nixpkgs: Maintainer information:
It's possible to override the buildPhase in to run make. However in this case it might be easier to just perform the remame with a in .

passthru.updateScript = ./update.sh; <ins> postInstall = '' mv $out/bin/wireguard $out/bin/wireguard-go ''; </ins> meta = with stdenv.lib; { description = "Userspace Go implementation of WireGuard"; homepage = "https://git.zx2c4.com/wireguard-go/about/";


Question:
Describe the bug Error build php packages. To Reproduce Steps to reproduce the behavior: Run Notify maintainers Build error occurs after this PR Build log:
After this PR error build php. cc
fixes it

hardeningDisable = [ "bindnow" ]; <del> preConfigure = '' # Don't record the configure flags since this causes unnecessary # runtime dependencies </del> <ins> preConfigure = # Don't record the configure flags since this causes unnecessary # runtime dependencies '' </ins> for i in main/build-defs.h.in scripts/php-config.in; do substituteInPlace $i  --replace '@CONFIGURE_COMMAND@' '(omitted)'


Question:
Describe the bug Error build php packages. To Reproduce Steps to reproduce the behavior: Run Notify maintainers Build error occurs after this PR Build log:
After this PR error build php. cc
fixes it

done export EXTENSION_DIR=$out/lib/php/extensions <ins> '' # PKG_CONFIG need not be a relative path + lib.optionalString (! lib.versionAtLeast version "7.4") '' for i in $(find . -type f -name "*.m4"); do substituteInPlace $i  --replace 'test -x "$PKG_CONFIG"' 'type -P "$PKG_CONFIG" >/dev/null' done '' + '' </ins> ./buildconf --copy --force if test -f $src/genfiles; then


Question:
The I wrote is failing on (): The problem is that when machines reboot in quick succession, consensus (and cluster leadership) is lost permanently, and 2-of-3 servers cannot continue to serve requests. I have debugged it and found that it is already broken since (), but it was noticed only now. :red_circle: This is why we should run the relevant tests for every PR and should show big red warning signs when they fail! In any case, I have bisected the problem to be commit , introduced between Consul and . I have filed an upstream bug: I also found a way to make the test pass: But I don't think that's good, because I think this is a fundamental issue with Consul that affects operations (the 2-of-3 HA promise being broken), so I think it should be fundamentally fixed, and that the test is right. NixOS 20.03 still has Consul so it does not suffer from this bug, but the next NixOS release will. CC as previous consule package contributors.
IMO we shouldn't even use attr, but always refer to concrete version, like or . Seamless major consul upgrade is fine in docs, but disaster in reality (happened twice to me). That doesn't quite solve this particular problem, I know.
Yes, the key thing is that Consul doesn't permit downgrades of its state in . I would thus also always recommend to upgrade non-point-releases separately from NixOS upgrades.
Honestly I kinda wanna make a few changes to most of the Hashi packages and tests soon to provide more stable versioning (and reliable testing). I'll start cleaning it up this weekend hopefully
Upstream has a great explanation and recommended fix: Test fix and more tests in PR . Key change: . I recommend every Consul user to read that linked comment and the updated test to understand the upstream-recommended rolling reboot/upgrade procedure.

server = index: { pkgs, ... }: let <del> ip = builtins.elemAt allConsensusServerHosts index; </del> <ins> numConsensusServers = builtins.length allConsensusServerHosts; thisConsensusServerHost = builtins.elemAt allConsensusServerHosts index; ip = thisConsensusServerHost; # since we already use IPs to identify servers </ins> in { networking.interfaces.eth1.ipv4.addresses = pkgs.lib.mkOverride 0 [ <del> { address = builtins.elemAt allConsensusServerHosts index; prefixLength = 16; } </del> <ins> { address = ip; prefixLength = 16; } </ins> ]; networking.firewall = firewallSettings; services.consul = <del> let thisConsensusServerHost = builtins.elemAt allConsensusServerHosts index; in </del> assert builtins.elem thisConsensusServerHost allConsensusServerHosts; { enable = true; inherit webUi; extraConfig = defaultExtraConfig // { server = true; <del> bootstrap_expect = builtins.length allConsensusServerHosts; </del> <ins> bootstrap_expect = numConsensusServers; # Tell Consul that we never intend to drop below this many servers. # Ensures to not permanently lose consensus after temporary loss. # See https://github.com/hashicorp/consul/issues/8118#issuecomment-645330040 autopilot.min_quorum = numConsensusServers; </ins> retry_join = # If there's only 1 node in the network, we allow self-join; # otherwise, the node must not try to join itself, and join only the other servers. # See https://github.com/hashicorp/consul/issues/2868 <del> if builtins.length allConsensusServerHosts == 1 </del> <ins> if numConsensusServers == 1 </ins> then allConsensusServerHosts else builtins.filter (h: h != thisConsensusServerHost) allConsensusServerHosts; bind_addr = ip;


Question:
The I wrote is failing on (): The problem is that when machines reboot in quick succession, consensus (and cluster leadership) is lost permanently, and 2-of-3 servers cannot continue to serve requests. I have debugged it and found that it is already broken since (), but it was noticed only now. :red_circle: This is why we should run the relevant tests for every PR and should show big red warning signs when they fail! In any case, I have bisected the problem to be commit , introduced between Consul and . I have filed an upstream bug: I also found a way to make the test pass: But I don't think that's good, because I think this is a fundamental issue with Consul that affects operations (the 2-of-3 HA promise being broken), so I think it should be fundamentally fixed, and that the test is right. NixOS 20.03 still has Consul so it does not suffer from this bug, but the next NixOS release will. CC as previous consule package contributors.
IMO we shouldn't even use attr, but always refer to concrete version, like or . Seamless major consul upgrade is fine in docs, but disaster in reality (happened twice to me). That doesn't quite solve this particular problem, I know.
Yes, the key thing is that Consul doesn't permit downgrades of its state in . I would thus also always recommend to upgrade non-point-releases separately from NixOS upgrades.
Honestly I kinda wanna make a few changes to most of the Hashi packages and tests soon to provide more stable versioning (and reliable testing). I'll start cleaning it up this weekend hopefully
Upstream has a great explanation and recommended fix: Test fix and more tests in PR . Key change: . I recommend every Consul user to read that linked comment and the updated test to understand the upstream-recommended rolling reboot/upgrade procedure.

for m in machines: m.wait_for_unit("consul.service") <del> for m in machines: m.wait_until_succeeds("[ $(consul members | grep -o alive | wc -l) == 5 ]") </del> <ins> def wait_for_healthy_servers(): # See https://github.com/hashicorp/consul/issues/8118#issuecomment-645330040 # for why the `Voter` column of `list-peers` has that info. # TODO: The `grep true` relies on the fact that currently in #       the output like #           # consul operator raft list-peers #           Node     ID   Address           State     Voter  RaftProtocol #           server3  ...  192.168.1.3:8300  leader    true   3 #           server2  ...  192.168.1.2:8300  follower  true   3 #           server1  ...  192.168.1.1:8300  follower  false  3 #       `Voter`is the only boolean column. #       Change this to the more reliable way to be defined by #       https://github.com/hashicorp/consul/issues/8118 #       once that ticket is closed. for m in machines: m.wait_until_succeeds( "[ $(consul operator raft list-peers | grep true | wc -l) == 3 ]" ) def wait_for_all_machines_alive(): """ Note that Serf-"alive" does not mean "Raft"-healthy; see `wait_for_healthy_servers()` for that instead. """ for m in machines: m.wait_until_succeeds("[ $(consul members | grep -o alive | wc -l) == 5 ]") wait_for_healthy_servers() # Also wait for clients to be alive. wait_for_all_machines_alive() </ins> client1.succeed("consul kv put testkey 42") client2.succeed("[ $(consul kv get testkey) == 42 ]") <del> # Test that the cluster can tolearate failures of any single server: for server in servers: server.crash() # For each client, wait until they have connection again # using `kv get -recurse` before issuing commands. client1.wait_until_succeeds("consul kv get -recurse") client2.wait_until_succeeds("consul kv get -recurse") </del> <ins> def rolling_reboot_test(proper_rolling_procedure=True): """ Tests that the cluster can tolearate failures of any single server, following the recommended rolling upgrade procedure from https://www.consul.io/docs/upgrading#standard-upgrades. </ins> <del> # Do some consul actions while one server is down. client1.succeed("consul kv put testkey 43") client2.succeed("[ $(consul kv get testkey) == 43 ]") client2.succeed("consul kv delete testkey") </del> <ins> Optionally, `proper_rolling_procedure=False` can be given to wait only for each server to be back `Healthy`, not `Stable` in the Raft consensus, see Consul setting `ServerStabilizationTime` and https://github.com/hashicorp/consul/issues/8118#issuecomment-645330040. """ for server in servers: server.crash() # For each client, wait until they have connection again # using `kv get -recurse` before issuing commands. client1.wait_until_succeeds("consul kv get -recurse") client2.wait_until_succeeds("consul kv get -recurse") </ins> <del> # Restart crashed machine. server.start() </del> <ins> # Do some consul actions while one server is down. client1.succeed("consul kv put testkey 43") client2.succeed("[ $(consul kv get testkey) == 43 ]") client2.succeed("consul kv delete testkey") # Restart crashed machine. server.start() if proper_rolling_procedure: # Wait for recovery. wait_for_healthy_servers() else: # NOT proper rolling upgrade procedure, see above. wait_for_all_machines_alive() # Wait for client connections. client1.wait_until_succeeds("consul kv get -recurse") client2.wait_until_succeeds("consul kv get -recurse") # Do some consul actions with server back up. client1.succeed("consul kv put testkey 44") client2.succeed("[ $(consul kv get testkey) == 44 ]") client2.succeed("consul kv delete testkey") def all_servers_crash_simultaneously_test(): """ Tests that the cluster will eventually come back after all servers crash simultaneously. """ for server in servers: server.crash() for server in servers: server.start() </ins> # Wait for recovery. <del> for m in machines: m.wait_until_succeeds("[ $(consul members | grep -o alive | wc -l) == 5 ]") </del> <ins> wait_for_healthy_servers() </ins> # Wait for client connections. client1.wait_until_succeeds("consul kv get -recurse") client2.wait_until_succeeds("consul kv get -recurse") <del> # Do some consul actions with server back up. </del> <ins> # Do some consul actions with servers back up. </ins> client1.succeed("consul kv put testkey 44") client2.succeed("[ $(consul kv get testkey) == 44 ]") client2.succeed("consul kv delete testkey") <ins> # Run the tests. print("rolling_reboot_test()") rolling_reboot_test() print("all_servers_crash_simultaneously_test()") all_servers_crash_simultaneously_test() print("rolling_reboot_test(proper_rolling_procedure=False)") rolling_reboot_test(proper_rolling_procedure=False) </ins> ''; })


Question: Describe the bug It should be the path to ca- To Reproduce Expected behavior No error happens. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(mnacamura): nixpkgs:

"--with-iconv=${libiconv}" "--with-dbm=gdbm" "--with-zlib=${zlib}" <del> "--with-ca-bundle=$NIX_SSL_CERT_FILE" </del> <ins> "--with-ca-bundle=${cacert}/etc/ssl/certs/ca-bundle.crt" </ins> # TODO: Enable slib #       Current slib in nixpkgs is specialized to Guile # "--with-slib=${slibGuile}/lib/slib"


Question:
, CVSSv3=9.8 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
merged
Need to keep open for 20.09
Merged to 20.09 too. Closing.

with stdenv.lib; stdenv.mkDerivation rec { <del> name = "corosync-2.4.3"; </del> <ins> pname = "corosync"; version = "2.4.5"; </ins> src = fetchurl { <del> url = "http://build.clusterlabs.org/corosync/releases/${name}.tar.gz"; sha256 = "15y5la04qn2lh1gabyifygzpa4dx3ndk5yhmaf7azxyjx0if9rxi"; </del> <ins> url = "http://build.clusterlabs.org/corosync/releases/${pname}-${version}.tar.gz"; sha256 = "0pxs18vci9kq3qnqsg5i1h35jrxxiccwbm0mzja3g8j3izdsyvmb"; </ins> }; nativeBuildInputs = [ makeWrapper pkgconfig ];


Question:
, CVSSv3=9.8 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
merged
Need to keep open for 20.09
Merged to 20.09 too. Closing.


Question: , CVSSv3=6.1 (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives. Cc Cc

<del> { lib, buildGoPackage, fetchFromGitHub }: </del> <ins> { lib, buildGoModule, fetchFromGitHub }: </ins> <del> buildGoPackage rec { pname = "oauth2_proxy"; version = "5.1.0"; goPackagePath = "github.com/pusher/${pname}"; </del> <ins> buildGoModule rec { pname = "oauth2-proxy"; version = "5.1.1"; </ins> src = fetchFromGitHub { repo = pname;


Question: , CVSSv3=6.1 (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives. Cc Cc

rev = "v${version}"; }; <del> goDeps = ./deps.nix; </del> <ins> vendorSha256 = "01lf7xbhgn5l42ahym12vr1w00zx1qzy6sgwgcbvvxp48k0b271d"; </ins> doCheck = true;


Question: , CVSSv3=6.1 (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives. Cc Cc

meta = with lib; { description = "A reverse proxy that provides authentication with Google, Github, or other providers"; <del> homepage = "https://github.com/pusher/oauth2_proxy/"; </del> <ins> homepage = "https://github.com/oauth2-proxy/oauth2-proxy/"; </ins> license = licenses.mit; maintainers = with maintainers; [ yorickvp knl ]; };


Question: , CVSSv3=6.1 (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives. Cc Cc

<del> # file generated from go.mod using vgo2nix (https://github.com/adisbladis/vgo2nix) [ { goPackagePath = "cloud.google.com/go"; fetch = { type = "git"; url = "https://code.googlesource.com/gocloud"; rev = "v0.38.0"; sha256 = "0n6n13b7lri2fmc4bn4ifszyawj31dpbzvyv0xafsf81440z8cyh"; }; } { goPackagePath = "github.com/BurntSushi/toml"; fetch = { type = "git"; url = "https://github.com/BurntSushi/toml"; rev = "v0.3.1"; sha256 = "1fjdwwfzyzllgiwydknf1pwjvy49qxfsczqx5gz3y0izs7as99j6"; }; } { goPackagePath = "github.com/alicebob/gopher-json"; fetch = { type = "git"; url = "https://github.com/alicebob/gopher-json"; rev = "5a6b3ba71ee6"; sha256 = "0hx6n722zq51p852lv56k39yjy09lw6mnr2c3x0p23rfyyrakj2p"; }; } { goPackagePath = "github.com/alicebob/miniredis"; fetch = { type = "git"; url = "https://github.com/alicebob/miniredis"; rev = "v2.11.2"; sha256 = "1fc6w9n1jznwj8ks2svxmjrv87pk3spjf5z3kcxpgpynp13pd55n"; }; } { goPackagePath = "github.com/bitly/go-simplejson"; fetch = { type = "git"; url = "https://github.com/bitly/go-simplejson"; rev = "v0.5.0"; sha256 = "0n9f9dz1jn1jx86d48569nznpjn9fmq3knn7r65xpy7jhih284jj"; }; } { goPackagePath = "github.com/bmizerany/assert"; fetch = { type = "git"; url = "https://github.com/bmizerany/assert"; rev = "b7ed37b82869"; sha256 = "18hy1wyl9zdi7sgxafrn3m7fadh6in0rhhb8l0cvkxqzdl0jcw2s"; }; } { goPackagePath = "github.com/census-instrumentation/opencensus-proto"; fetch = { type = "git"; url = "https://github.com/census-instrumentation/opencensus-proto"; rev = "v0.2.1"; sha256 = "19fcx3sc99i5dsklny6r073z5j20vlwn2xqm6di1q3b1xwchzqfj"; }; } { goPackagePath = "github.com/chzyer/logex"; fetch = { type = "git"; url = "https://github.com/chzyer/logex"; rev = "v1.1.10"; sha256 = "08pbjj3wx9acavlwyr055isa8a5hnmllgdv5k6ra60l5y1brmlq4"; }; } { goPackagePath = "github.com/chzyer/readline"; fetch = { type = "git"; url = "https://github.com/chzyer/readline"; rev = "2972be24d48e"; sha256 = "104q8dazj8yf6b089jjr82fy9h1g80zyyzvp3g8b44a7d8ngjj6r"; }; } { goPackagePath = "github.com/chzyer/test"; fetch = { type = "git"; url = "https://github.com/chzyer/test"; rev = "a1ea475d72b1"; sha256 = "0rns2aqk22i9xsgyap0pq8wi4cfaxsri4d9q6xxhhyma8jjsnj2k"; }; } { goPackagePath = "github.com/client9/misspell"; fetch = { type = "git"; url = "https://github.com/client9/misspell"; rev = "v0.3.4"; sha256 = "1vwf33wsc4la25zk9nylpbp9px3svlmldkm0bha4hp56jws4q9cs"; }; } { goPackagePath = "github.com/coreos/go-oidc"; fetch = { type = "git"; url = "https://github.com/coreos/go-oidc"; rev = "v2.2.1"; sha256 = "11m6slbpi33ynffml7812piq4anhjlf1qszjlsf26f5y7x3qh8n5"; }; } { goPackagePath = "github.com/davecgh/go-spew"; fetch = { type = "git"; url = "https://github.com/davecgh/go-spew"; rev = "v1.1.0"; sha256 = "0d4jfmak5p6lb7n2r6yvf5p1zcw0l8j74kn55ghvr7zr7b7axm6c"; }; } { goPackagePath = "github.com/dgrijalva/jwt-go"; fetch = { type = "git"; url = "https://github.com/dgrijalva/jwt-go"; rev = "v3.2.0"; sha256 = "08m27vlms74pfy5z79w67f9lk9zkx6a9jd68k3c4msxy75ry36mp"; }; } { goPackagePath = "github.com/envoyproxy/go-control-plane"; fetch = { type = "git"; url = "https://github.com/envoyproxy/go-control-plane"; rev = "5f8ba28d4473"; sha256 = "1f1s764rd41vd9vgk3r14h1m6fz6pdvxj6fd83q58gxifbc4q5w4"; }; } { goPackagePath = "github.com/envoyproxy/protoc-gen-validate"; fetch = { type = "git"; url = "https://github.com/envoyproxy/protoc-gen-validate"; rev = "v0.1.0"; sha256 = "0kxd3wwh3xwqk0r684hsy281xq4y71cd11d4q2hspcjbnlbwh7cy"; }; } { goPackagePath = "github.com/fsnotify/fsnotify"; fetch = { type = "git"; url = "https://github.com/fsnotify/fsnotify"; rev = "v1.4.7"; sha256 = "07va9crci0ijlivbb7q57d2rz9h27zgn2fsm60spjsqpdbvyrx4g"; }; } { goPackagePath = "github.com/go-redis/redis"; fetch = { type = "git"; url = "https://github.com/go-redis/redis"; rev = "v6.15.7"; sha256 = "0fc0sfispyzn652ny05wn6bz18a60n6ryk23ki8j97xx3l24nq2g"; }; } { goPackagePath = "github.com/golang/glog"; fetch = { type = "git"; url = "https://github.com/golang/glog"; rev = "23def4e6c14b"; sha256 = "0jb2834rw5sykfr937fxi8hxi2zy80sj2bdn9b3jb4b26ksqng30"; }; } { goPackagePath = "github.com/golang/mock"; fetch = { type = "git"; url = "https://github.com/golang/mock"; rev = "v1.2.0"; sha256 = "12ddj2g8ab87id6n2n67vnbhq6p8dvgsq1pzpqfriym4dk8w54fg"; }; } { goPackagePath = "github.com/golang/protobuf"; fetch = { type = "git"; url = "https://github.com/golang/protobuf"; rev = "v1.3.2"; sha256 = "1k1wb4zr0qbwgpvz9q5ws9zhlal8hq7dmq62pwxxriksayl6hzym"; }; } { goPackagePath = "github.com/gomodule/redigo"; fetch = { type = "git"; url = "https://github.com/gomodule/redigo"; rev = "v2.0.0"; sha256 = "1kg7s8027b4g1sfw0v3nh30c15j407kv684s53gg281r807dnfpk"; }; } { goPackagePath = "github.com/google/btree"; fetch = { type = "git"; url = "https://github.com/google/btree"; rev = "4030bb1f1f0c"; sha256 = "0ba430m9fbnagacp57krgidsyrgp3ycw5r7dj71brgp5r52g82p6"; }; } { goPackagePath = "github.com/google/go-cmp"; fetch = { type = "git"; url = "https://github.com/google/go-cmp"; rev = "v0.3.0"; sha256 = "1hyxx3434zshl2m9ja78gwlkg1rx9yl6diqa7dnjb31xz5x4gbjj"; }; } { goPackagePath = "github.com/google/martian"; fetch = { type = "git"; url = "https://github.com/google/martian"; rev = "v2.1.0"; sha256 = "197hil6vrjk50b9wvwyzf61csid83whsjj6ik8mc9r2lryxlyyrp"; }; } { goPackagePath = "github.com/google/pprof"; fetch = { type = "git"; url = "https://github.com/google/pprof"; rev = "3ea8567a2e57"; sha256 = "09rhjn3ms0a72dw0yzbp237p7yhqma772zspddn6mgkh3gi3kn4c"; }; } { goPackagePath = "github.com/googleapis/gax-go"; fetch = { type = "git"; url = "https://github.com/googleapis/gax-go"; rev = "v2.0.5"; sha256 = "1lxawwngv6miaqd25s3ba0didfzylbwisd2nz7r4gmbmin6jsjrx"; }; } { goPackagePath = "github.com/hashicorp/golang-lru"; fetch = { type = "git"; url = "https://github.com/hashicorp/golang-lru"; rev = "v0.5.1"; sha256 = "13f870cvk161bzjj6x41l45r5x9i1z9r2ymwmvm7768kg08zznpy"; }; } { goPackagePath = "github.com/hpcloud/tail"; fetch = { type = "git"; url = "https://github.com/hpcloud/tail"; rev = "v1.0.0"; sha256 = "1njpzc0pi1acg5zx9y6vj9xi6ksbsc5d387rd6904hy6rh2m6kn0"; }; } { goPackagePath = "github.com/jstemmer/go-junit-report"; fetch = { type = "git"; url = "https://github.com/jstemmer/go-junit-report"; rev = "af01ea7f8024"; sha256 = "1lp3n94ris12hac02wi31f3whs88lcrzwgdg43a5j6cafg9p1d0s"; }; } { goPackagePath = "github.com/kr/pretty"; fetch = { type = "git"; url = "https://github.com/kr/pretty"; rev = "v0.2.0"; sha256 = "1ywbfzz1h3a3qd8rpkiqwi1dm4w8ls9ijb4x1b7567grns9f0vnp"; }; } { goPackagePath = "github.com/kr/pty"; fetch = { type = "git"; url = "https://github.com/kr/pty"; rev = "v1.1.1"; sha256 = "0383f0mb9kqjvncqrfpidsf8y6ns5zlrc91c6a74xpyxjwvzl2y6"; }; } { goPackagePath = "github.com/kr/text"; fetch = { type = "git"; url = "https://github.com/kr/text"; rev = "v0.1.0"; sha256 = "1gm5bsl01apvc84bw06hasawyqm4q84vx1pm32wr9jnd7a8vjgj1"; }; } { goPackagePath = "github.com/mbland/hmacauth"; fetch = { type = "git"; url = "https://github.com/mbland/hmacauth"; rev = "44256dfd4bfa"; sha256 = "1d5pbjgc5j8pi3frsjp5gqg7j12bxdbl55nhy01cv4c96hay2ij1"; }; } { goPackagePath = "github.com/mreiferson/go-options"; fetch = { type = "git"; url = "https://github.com/mreiferson/go-options"; rev = "v1.0.0"; sha256 = "1pxs9ybrh196qy14ijn4zn51h2z28lj31y6vxrz2xxhgvpmfmxyl"; }; } { goPackagePath = "github.com/onsi/ginkgo"; fetch = { type = "git"; url = "https://github.com/onsi/ginkgo"; rev = "v1.12.0"; sha256 = "0ly246i0ax53l6dn9f1zlhkd9gs03hvbk7aazxay2dd5fxzh9n65"; }; } { goPackagePath = "github.com/onsi/gomega"; fetch = { type = "git"; url = "https://github.com/onsi/gomega"; rev = "v1.9.0"; sha256 = "0l69r6nbnz6b3j9zrqn8aql88jjv1pqykzkvqdbhfprss9b2dy46"; }; } { goPackagePath = "github.com/pmezard/go-difflib"; fetch = { type = "git"; url = "https://github.com/pmezard/go-difflib"; rev = "v1.0.0"; sha256 = "0c1cn55m4rypmscgf0rrb88pn58j3ysvc2d0432dp3c6fqg6cnzw"; }; } { goPackagePath = "github.com/pquerna/cachecontrol"; fetch = { type = "git"; url = "https://github.com/pquerna/cachecontrol"; rev = "1555304b9b35"; sha256 = "0nr3p9pms6jmr2s44vy2s22q1d3v6xns2kzsvkq2gg1rkx6c1hc9"; }; } { goPackagePath = "github.com/prometheus/client_model"; fetch = { type = "git"; url = "https://github.com/prometheus/client_model"; rev = "14fe0d1b01d4"; sha256 = "0zdmk6rbbx39cvfz0r59v2jg5sg9yd02b4pds5n5llgvivi99550"; }; } { goPackagePath = "github.com/stretchr/objx"; fetch = { type = "git"; url = "https://github.com/stretchr/objx"; rev = "v0.1.0"; sha256 = "19ynspzjdynbi85xw06mh8ad5j0qa1vryvxjgvbnyrr8rbm4vd8w"; }; } { goPackagePath = "github.com/stretchr/testify"; fetch = { type = "git"; url = "https://github.com/stretchr/testify"; rev = "v1.5.1"; sha256 = "09r89m1wy4cjv2nps1ykp00qjpi0531r07q3s34hr7m6njk4srkl"; }; } { goPackagePath = "github.com/yhat/wsutil"; fetch = { type = "git"; url = "https://github.com/yhat/wsutil"; rev = "1d66fa95c997"; sha256 = "1agh4ss6y1laps8pg4mdl844ivmw2wrb7rnpfyag4gai4693i7bv"; }; } { goPackagePath = "github.com/yuin/gopher-lua"; fetch = { type = "git"; url = "https://github.com/yuin/gopher-lua"; rev = "ab39c6098bdb"; sha256 = "13b0rrpv3988qw8rq6z7npajn1my059ybhafi5mxff9jw09k9sja"; }; } { goPackagePath = "go.opencensus.io"; fetch = { type = "git"; url = "https://github.com/census-instrumentation/opencensus-go"; rev = "v0.21.0"; sha256 = "14s0a12xdzjvad0dgksgv8m3hh7nc585abvjkvyk6r67a29lxj6x"; }; } { goPackagePath = "golang.org/x/crypto"; fetch = { type = "git"; url = "https://go.googlesource.com/crypto"; rev = "2aa609cf4a9d"; sha256 = "1yvis6fqbsd7f356aqyi18f76vnwj3bry6mxqnkvshq4cwrf92il"; }; } { goPackagePath = "golang.org/x/exp"; fetch = { type = "git"; url = "https://go.googlesource.com/exp"; rev = "509febef88a4"; sha256 = "02isrh39z8znrp5znplzy0dip2gnrl3jm1355raliyvhnhg04j6q"; }; } { goPackagePath = "golang.org/x/lint"; fetch = { type = "git"; url = "https://go.googlesource.com/lint"; rev = "959b441ac422"; sha256 = "1mgcv5f00pkzsbwnq2y7vqvd1b4lr5a3s47cphh2qv4indfk7pck"; }; } { goPackagePath = "golang.org/x/net"; fetch = { type = "git"; url = "https://go.googlesource.com/net"; rev = "0de0cce0169b"; sha256 = "1db7s5kbzyh2zd5lpv05n7hp8wbwdvgk0wpiwrlnig94mkr0y5aq"; }; } { goPackagePath = "golang.org/x/oauth2"; fetch = { type = "git"; url = "https://go.googlesource.com/oauth2"; rev = "bf48bf16ab8d"; sha256 = "1sirdib60zwmh93kf9qrx51r8544k1p9rs5mk0797wibz3m4mrdg"; }; } { goPackagePath = "golang.org/x/sync"; fetch = { type = "git"; url = "https://go.googlesource.com/sync"; rev = "112230192c58"; sha256 = "05i2k43j2d0llq768hg5pf3hb2yhfzp9la1w5wp0rsnnzblr0lfn"; }; } { goPackagePath = "golang.org/x/sys"; fetch = { type = "git"; url = "https://go.googlesource.com/sys"; rev = "bd437916bb0e"; sha256 = "1i8x26frmlin55k69k936zd1rp5sqnq14y5ms4rkxbfzhasdm2rx"; }; } { goPackagePath = "golang.org/x/text"; fetch = { type = "git"; url = "https://go.googlesource.com/text"; rev = "v0.3.2"; sha256 = "0flv9idw0jm5nm8lx25xqanbkqgfiym6619w575p7nrdh0riqwqh"; }; } { goPackagePath = "golang.org/x/time"; fetch = { type = "git"; url = "https://go.googlesource.com/time"; rev = "85acf8d2951c"; sha256 = "0yqnxsrarjk4qkda8kcxzmk7y90kkkxzx9iwryzrk7bzs87ky3xc"; }; } { goPackagePath = "golang.org/x/tools"; fetch = { type = "git"; url = "https://go.googlesource.com/tools"; rev = "2c0ae7006135"; sha256 = "1lsi2ssxajclj3bciz2a41v1vjv768ja3v6wnbyhxy8xphwkp4fk"; }; } { goPackagePath = "golang.org/x/xerrors"; fetch = { type = "git"; url = "https://go.googlesource.com/xerrors"; rev = "a985d3407aa7"; sha256 = "00wzr5w8aadipgc3rkk8f11i41znskfj9ix5nhhaxyg7isrslgcj"; }; } { goPackagePath = "google.golang.org/api"; fetch = { type = "git"; url = "https://code.googlesource.com/google-api-go-client"; rev = "v0.19.0"; sha256 = "0rbwijzl91xmbr9kqhiwx4fydm7r6ci6rxsi9jsy8zap9zy120f6"; }; } { goPackagePath = "google.golang.org/appengine"; fetch = { type = "git"; url = "https://github.com/golang/appengine"; rev = "v1.5.0"; sha256 = "0l7mkdnwhidv8m686x432vmx8z5nqcrr9f46ddgvrxbh4wvyfcll"; }; } { goPackagePath = "google.golang.org/genproto"; fetch = { type = "git"; url = "https://github.com/google/go-genproto"; rev = "24fa4b261c55"; sha256 = "109zhaqlfd8zkbr1hk6zqbs6vcxfrk64scjwh2nswph05gr0m84d"; }; } { goPackagePath = "google.golang.org/grpc"; fetch = { type = "git"; url = "https://github.com/grpc/grpc-go"; rev = "v1.27.0"; sha256 = "1ijrmgrxyabfn51nm3p9l81iaasq5fg237wnr6mdc4dzsfcg8kd7"; }; } { goPackagePath = "gopkg.in/check.v1"; fetch = { type = "git"; url = "https://gopkg.in/check.v1"; rev = "20d25e280405"; sha256 = "0k1m83ji9l1a7ng8a7v40psbymxasmssbrrhpdv2wl4rhs0nc3np"; }; } { goPackagePath = "gopkg.in/fsnotify.v1"; fetch = { type = "git"; url = "https://gopkg.in/fsnotify.v1"; rev = "v1.4.7"; sha256 = "07va9crci0ijlivbb7q57d2rz9h27zgn2fsm60spjsqpdbvyrx4g"; }; } { goPackagePath = "gopkg.in/fsnotify/fsnotify.v1"; fetch = { type = "git"; url = "https://gopkg.in/fsnotify/fsnotify.v1"; rev = "v1.4.7"; sha256 = "07va9crci0ijlivbb7q57d2rz9h27zgn2fsm60spjsqpdbvyrx4g"; }; } { goPackagePath = "gopkg.in/natefinch/lumberjack.v2"; fetch = { type = "git"; url = "https://gopkg.in/natefinch/lumberjack.v2"; rev = "v2.0.0"; sha256 = "1m2sxypk7p805jvc68padvylyx5v7cwkh5klnnxxr0340kgspf08"; }; } { goPackagePath = "gopkg.in/square/go-jose.v2"; fetch = { type = "git"; url = "https://gopkg.in/square/go-jose.v2"; rev = "v2.4.1"; sha256 = "1y0angxwryishwd1z0q7fp2xwjjhpw70kqh4ml4ly40akfhf1f5a"; }; } { goPackagePath = "gopkg.in/tomb.v1"; fetch = { type = "git"; url = "https://gopkg.in/tomb.v1"; rev = "dd632973f1e7"; sha256 = "1lqmq1ag7s4b3gc3ddvr792c5xb5k6sfn0cchr3i2s7f1c231zjv"; }; } { goPackagePath = "gopkg.in/yaml.v2"; fetch = { type = "git"; url = "https://gopkg.in/yaml.v2"; rev = "v2.2.4"; sha256 = "11bwj757wi8kdrcnlgfqb8vv2d2xdhlghmyagd19i62khrkchsg2"; }; } { goPackagePath = "honnef.co/go/tools"; fetch = { type = "git"; url = "https://github.com/dominikh/go-tools"; rev = "ea95bdfd59fc"; sha256 = "1763nw7pwpzkvzfnm63dgzcgbq9hwmq5l1nffchnhh77vgkaq4ic"; }; } ] </del>


Question:
I am failing to install on right now: What more details should I provide?
perf fails on kernel 4.1 and 4.2 only
for an (arguably hacky) fix.

{stdenv, fetchurl}: stdenv.mkDerivation rec { <del> name = "ncompress-4.2.4.3"; </del> <ins> name = "ncompress-4.2.4.4"; </ins> builder = ./builder.sh;


Question:
I am failing to install on right now: What more details should I provide?
perf fails on kernel 4.1 and 4.2 only
for an (arguably hacky) fix.

src = fetchurl { url = "mirror://sourceforge/project/ncompress/${name}.tar.gz"; <del> sha256 = "1y44ixc1w2vfvj1lm4dkcljlwv882ynrvm5i6l0lg1gf883j246l"; </del> <ins> sha256 = "0yjiwv1hwb253x3m6r1dq2k7m5c9nz0ib2j7fnm3hark7y6s42xh"; </ins> }; meta = {


Question:
I am failing to install on right now: What more details should I provide?
perf fails on kernel 4.1 and 4.2 only
for an (arguably hacky) fix.

# perf refers both to newt and slang # binutils is required for libbfd. nativeBuildInputs = [ asciidoc xmlto docbook_xsl docbook_xml_dtd_45 libxslt flex bison ]; <del> buildInputs = [ elfutils python perl newt slang pkgconfig libunwind binutils ] ++ </del> <ins> buildInputs = [ python perl newt slang pkgconfig libunwind binutils ] ++ </ins> stdenv.lib.optional withGtk gtk; <del> NIX_CFLAGS_COMPILE = "-Wno-error=cpp"; </del> <ins> # Note: we don't add elfutils to buildInputs, since it provides a # bad `ld' and other stuff. NIX_CFLAGS_COMPILE = "-I${elfutils}/include -Wno-error=cpp"; NIX_CFLAGS_LINK = "-L${elfutils}/lib"; </ins> installFlags = "install install-man ASCIIDOC8=1";


Question:
Project description Netdata agent plugin Metadata homepage URL: source URL: license: GPL 3.0 platforms: unix, linux, darwin We already do have netdata, however it seems to be built without support for the cloud agent that allows it to stream to the cloud or other netdata servers.
I have a local checkout with some edits that allow me to build netdata with cloud support. Unfortunately they also require a change in the libwebsockets build expression. Should I open a PR to integrate my changes into nixpkgs?
A PR would be great! I'm not a maintainer, but if they decide it's out of scope for nixpkgs, perhaps one on NUR might work - I'd try for a PR here first though
Great, I think having a configuration option that is per default would make sense. Maybe ?
Yeah, that seems to fall in line with the various flags present in other packages
I marked this as stale due to inactivity. →
Upstream has incorporated some of the suggestions in this thread, I intend to pick up on it again soon
what would be needed to make this work? Perhaps I can help?
The newest major release of Netdata (1.30.0) includes a cloud link implementation without the need for vendored dependencies. Unfortunately, it is not currently in a reliable state because of a bug in the custom HTTPS implementation. The has already been merged into Netdata master and will be included in the next release. I plan to make a PR that enables cloud support as soon as that release is available.
v1.31.0 dropped 12 minutes ago :) Anything I can do to help?
Thanks, I've already gotten a notification for that. Planning to make a PR when I get off work today. When my PR is done, it would be helpful if you could test my changes on your machines.
Just FYI, I have opened the PR that enables cloud support a few days ago. If you are still interested it would be greatly appreciated if you could test if everything works for you and maybe drop a comment.
Sorry, missed this but the pr looks good! I propose we backport this to stable?

{ lib, stdenv, callPackage, fetchFromGitHub, autoreconfHook, pkg-config , CoreFoundation, IOKit, libossp_uuid <del> , curl, libcap,  libuuid, lm_sensors, zlib </del> , nixosTests <ins> , curl, libcap, libuuid, lm_sensors, zlib </ins> , withCups ? false, cups , withDBengine ? true, libuv, lz4, judy , withIpmi ? (!stdenv.isDarwin), freeipmi , withNetfilter ? (!stdenv.isDarwin), libmnl, libnetfilter_acct <ins> , withCloud ? (!stdenv.isDarwin), json_c </ins> , withSsl ? true, openssl , withDebug ? false <del> , fetchpatch </del> }: with lib;


Question:
Project description Netdata agent plugin Metadata homepage URL: source URL: license: GPL 3.0 platforms: unix, linux, darwin We already do have netdata, however it seems to be built without support for the cloud agent that allows it to stream to the cloud or other netdata servers.
I have a local checkout with some edits that allow me to build netdata with cloud support. Unfortunately they also require a change in the libwebsockets build expression. Should I open a PR to integrate my changes into nixpkgs?
A PR would be great! I'm not a maintainer, but if they decide it's out of scope for nixpkgs, perhaps one on NUR might work - I'd try for a PR here first though
Great, I think having a configuration option that is per default would make sense. Maybe ?
Yeah, that seems to fall in line with the various flags present in other packages
I marked this as stale due to inactivity. →
Upstream has incorporated some of the suggestions in this thread, I intend to pick up on it again soon
what would be needed to make this work? Perhaps I can help?
The newest major release of Netdata (1.30.0) includes a cloud link implementation without the need for vendored dependencies. Unfortunately, it is not currently in a reliable state because of a bug in the custom HTTPS implementation. The has already been merged into Netdata master and will be included in the next release. I plan to make a PR that enables cloud support as soon as that release is available.
v1.31.0 dropped 12 minutes ago :) Anything I can do to help?
Thanks, I've already gotten a notification for that. Planning to make a PR when I get off work today. When my PR is done, it would be helpful if you could test my changes on your machines.
Just FYI, I have opened the PR that enables cloud support a few days ago. If you are still interested it would be greatly appreciated if you could test if everything works for you and maybe drop a comment.
Sorry, missed this but the pr looks good! I propose we backport this to stable?

let go-d-plugin = callPackage ./go.d.plugin.nix {}; in stdenv.mkDerivation rec { <del> version = "1.30.1"; </del> <ins> version = "1.31.0"; </ins> pname = "netdata"; src = fetchFromGitHub { owner = "netdata"; repo = "netdata"; rev = "v${version}"; <del> sha256 = "0cp6gbn38f1cr0jkr64vvwz005cvnwj3hgfxs147wap9w228k46r"; </del> <ins> sha256 = "0735cxmljrp8zlkcq7hcxizy4j4xiv7vf782zkz5chn06n38mcik"; fetchSubmodules = true; </ins> }; nativeBuildInputs = [ autoreconfHook pkg-config ];


Question:
Project description Netdata agent plugin Metadata homepage URL: source URL: license: GPL 3.0 platforms: unix, linux, darwin We already do have netdata, however it seems to be built without support for the cloud agent that allows it to stream to the cloud or other netdata servers.
I have a local checkout with some edits that allow me to build netdata with cloud support. Unfortunately they also require a change in the libwebsockets build expression. Should I open a PR to integrate my changes into nixpkgs?
A PR would be great! I'm not a maintainer, but if they decide it's out of scope for nixpkgs, perhaps one on NUR might work - I'd try for a PR here first though
Great, I think having a configuration option that is per default would make sense. Maybe ?
Yeah, that seems to fall in line with the various flags present in other packages
I marked this as stale due to inactivity. →
Upstream has incorporated some of the suggestions in this thread, I intend to pick up on it again soon
what would be needed to make this work? Perhaps I can help?
The newest major release of Netdata (1.30.0) includes a cloud link implementation without the need for vendored dependencies. Unfortunately, it is not currently in a reliable state because of a bug in the custom HTTPS implementation. The has already been merged into Netdata master and will be included in the next release. I plan to make a PR that enables cloud support as soon as that release is available.
v1.31.0 dropped 12 minutes ago :) Anything I can do to help?
Thanks, I've already gotten a notification for that. Planning to make a PR when I get off work today. When my PR is done, it would be helpful if you could test my changes on your machines.
Just FYI, I have opened the PR that enables cloud support a few days ago. If you are still interested it would be greatly appreciated if you could test if everything works for you and maybe drop a comment.
Sorry, missed this but the pr looks good! I propose we backport this to stable?

++ optionals withDBengine [ libuv lz4.dev judy ] ++ optionals withIpmi [ freeipmi ] ++ optionals withNetfilter [ libmnl libnetfilter_acct ] <ins> ++ optionals withCloud [ json_c ] </ins> ++ optionals withSsl [ openssl.dev ]; patches = [ # required to prevent plugins from relying on /etc # and /var ./no-files-in-etc-and-var.patch <del> # cgroups: fix network interfaces detection when using virsh (fetchpatch { url = "https://patch-diff.githubusercontent.com/raw/netdata/netdata/pull/11096.patch"; sha256 = "0f2rd7kgbwbyq9wyn085d213ifvivnpl3qlx1gjrg42rkbi4n8jj"; }) </del> ]; NIX_CFLAGS_COMPILE = optionalString withDebug "-O1 -ggdb -DNETDATA_INTERNAL_CHECKS=1";


Question:
Project description Netdata agent plugin Metadata homepage URL: source URL: license: GPL 3.0 platforms: unix, linux, darwin We already do have netdata, however it seems to be built without support for the cloud agent that allows it to stream to the cloud or other netdata servers.
I have a local checkout with some edits that allow me to build netdata with cloud support. Unfortunately they also require a change in the libwebsockets build expression. Should I open a PR to integrate my changes into nixpkgs?
A PR would be great! I'm not a maintainer, but if they decide it's out of scope for nixpkgs, perhaps one on NUR might work - I'd try for a PR here first though
Great, I think having a configuration option that is per default would make sense. Maybe ?
Yeah, that seems to fall in line with the various flags present in other packages
I marked this as stale due to inactivity. →
Upstream has incorporated some of the suggestions in this thread, I intend to pick up on it again soon
what would be needed to make this work? Perhaps I can help?
The newest major release of Netdata (1.30.0) includes a cloud link implementation without the need for vendored dependencies. Unfortunately, it is not currently in a reliable state because of a bug in the custom HTTPS implementation. The has already been merged into Netdata master and will be included in the next release. I plan to make a PR that enables cloud support as soon as that release is available.
v1.31.0 dropped 12 minutes ago :) Anything I can do to help?
Thanks, I've already gotten a notification for that. Planning to make a PR when I get off work today. When my PR is done, it would be helpful if you could test my changes on your machines.
Just FYI, I have opened the PR that enables cloud support a few days ago. If you are still interested it would be greatly appreciated if you could test if everything works for you and maybe drop a comment.
Sorry, missed this but the pr looks good! I propose we backport this to stable?

configureFlags = [ "--localstatedir=/var" "--sysconfdir=/etc" <ins> ] ++ optionals withCloud [ "--enable-cloud" "--with-aclk-ng" </ins> ]; postFixup = ''


Question:
Describe the bug , a package which requires PySide2, fails to install, either system-wide, nix-env local, nix-env global, or with home-manager. To Reproduce Results Running the above command: Expected behavior Syncplay installs correctly without error. Notify maintainers pyside2: syncplay: Metadata Please run and paste the result.
This not only affects syncplay. Many other dependencies are broken as well. Freecad for instance does not build either.
looks like updating pyside2 to 5.12.6 fixed this issue on my fork:
Your fix looks good to me. Could you PR it?
done,

stdenv.mkDerivation rec { pname = "pyside2"; <del> version = "5.12.3"; </del> <ins> version = "5.12.6"; </ins> src = fetchurl { url = "https://download.qt.io/official_releases/QtForPython/pyside2/PySide2-${version}-src/pyside-setup-everywhere-src-${version}.tar.xz"; <del> sha256 = "0hk89jm8pa0q6kifask5rrffa3bvx02dg2f97ibv7wds9dysnyjg"; </del> <ins> sha256 = "1n45l6xxyxs6cfp2l4rp8qs1c2fyfwyrdxa4qcpwfsqsi51rydsk"; </ins> }; patches = [


Question:
Describe the bug , a package which requires PySide2, fails to install, either system-wide, nix-env local, nix-env global, or with home-manager. To Reproduce Results Running the above command: Expected behavior Syncplay installs correctly without error. Notify maintainers pyside2: syncplay: Metadata Please run and paste the result.
This not only affects syncplay. Many other dependencies are broken as well. Freecad for instance does not build either.
looks like updating pyside2 to 5.12.6 fixed this issue on my fork:
Your fix looks good to me. Could you PR it?
done,

<del> --- pyside-setup-everywhere-src-5.12.3/sources/shiboken2/ApiExtractor/clangparser/compilersupport.cpp~	2019-06-15 10:31:04.712949189 +0200 +++ pyside-setup-everywhere-src-5.12.3/sources/shiboken2/ApiExtractor/clangparser/compilersupport.cpp	2019-06-15 11:52:52.894987343 +0200 @@ -317,15 +317,15 @@ </del> <ins> --- pyside-setup-everywhere-src-5.12.6/sources/shiboken2/ApiExtractor/clangparser/compilersupport.cpp~	2020-07-08 14:37:13.022476435 -0700 +++ pyside-setup-everywhere-src-5.12.6/sources/shiboken2/ApiExtractor/clangparser/compilersupport.cpp	2020-07-08 14:37:18.271484269 -0700 @@ -330,17 +330,15 @@ </ins> } #endif // NEED_CLANG_BUILTIN_INCLUDES


Question:
Describe the bug , a package which requires PySide2, fails to install, either system-wide, nix-env local, nix-env global, or with home-manager. To Reproduce Results Running the above command: Expected behavior Syncplay installs correctly without error. Notify maintainers pyside2: syncplay: Metadata Please run and paste the result.
This not only affects syncplay. Many other dependencies are broken as well. Freecad for instance does not build either.
looks like updating pyside2 to 5.12.6 fixed this issue on my fork:
Your fix looks good to me. Could you PR it?
done,

-    // A fix for this has been added to Clang 5.0, so, the code can be removed -    // once Clang 5.0 is the minimum version. -    if (needsGppInternalHeaders()) { <del> -        const HeaderPaths gppPaths = gppInternalIncludePaths(QStringLiteral("g++")); </del> <ins> -        const HeaderPaths gppPaths = gppInternalIncludePaths(compilerFromCMake(QStringLiteral("g++"))); </ins> -        for (const HeaderPath &h : gppPaths) { <del> -            if (h.path.contains("c++")) </del> <ins> -            if (h.path.contains("c++") -                || h.path.contains("sysroot")) { // centOS </ins> -                headerPaths.append(h); <ins> -            } </ins> +    const HeaderPaths gppPaths = gppInternalIncludePaths(QStringLiteral("g++")); +    for (const HeaderPath &h : gppPaths) { +        // PySide2 requires that Qt headers are not -isystem


Question: Describe the bug oneDNN is a dependency of pytorch. Today, oneDNN's are all linux-based but oneDNN actually appears to compile fine on ; its tests just all immediately fail because of RPATH problems. To Reproduce Expected behavior I expect oneDNN to build and check successfully. Additional context I think that this problem may be able to be fixed by adding in on Darwin, much like is currently set and exported. Note, for even more detail/context on CMake's support for controlling RPATH on macOS, please see Notify maintainers Metadata (Note, I am actually testing this using nix flakes, with this ) Maintainer information:

# https://github.com/oneapi-src/oneDNN#oneapi-deep-neural-network-library-onednn stdenv.mkDerivation rec { pname = "oneDNN"; <del> version = "1.5"; </del> <ins> version = "1.5.1"; </ins> src = fetchFromGitHub { owner = "oneapi-src"; repo = "oneDNN"; rev = "v${version}"; <del> sha256 = "0diiy3g4wz5lnz5mdvka5p2nwmrpfldsz83sssr5yiir29m4lqap"; </del> <ins> sha256 = "1l66gkidldjpznp8pb01wdgrmm0rmrbndv8lzidz8fp9hf473zgl"; </ins> }; outputs = [ "out" "dev" "doc" ];


Question: Describe the bug oneDNN is a dependency of pytorch. Today, oneDNN's are all linux-based but oneDNN actually appears to compile fine on ; its tests just all immediately fail because of RPATH problems. To Reproduce Expected behavior I expect oneDNN to build and check successfully. Additional context I think that this problem may be able to be fixed by adding in on Darwin, much like is currently set and exported. Note, for even more detail/context on CMake's support for controlling RPATH on macOS, please see Notify maintainers Metadata (Note, I am actually testing this using nix flakes, with this ) Maintainer information:

# The test driver doesn't add an RPath to the build libdir preCheck = '' <del> export LD_LIBRARY_PATH=$PWD/src </del> <ins> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH''${LD_LIBRARY_PATH:+:}$PWD/src export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH''${DYLD_LIBRARY_PATH:+:}$PWD/src </ins> ''; # The cmake install gets tripped up and installs a nix tree into $out, in


Question: Describe the bug oneDNN is a dependency of pytorch. Today, oneDNN's are all linux-based but oneDNN actually appears to compile fine on ; its tests just all immediately fail because of RPATH problems. To Reproduce Expected behavior I expect oneDNN to build and check successfully. Additional context I think that this problem may be able to be fixed by adding in on Darwin, much like is currently set and exported. Note, for even more detail/context on CMake's support for controlling RPATH on macOS, please see Notify maintainers Metadata (Note, I am actually testing this using nix flakes, with this ) Maintainer information:

meta = with lib; { description = "oneAPI Deep Neural Network Library (oneDNN)"; <del> homepage = "https://01.org/dnnl"; </del> <ins> homepage = "https://01.org/oneDNN"; </ins> changelog = "https://github.com/oneapi-src/oneDNN/releases/tag/v${version}"; license = licenses.asl20; <del> platforms = [ "aarch64-linux" "x86_64-linux" ]; </del> <ins> platforms = platforms.all; </ins> maintainers = with maintainers; [ alexarice bhipple ]; }; }


Question:
Describe the bug AppImages assume that the gmp library is present on the system, but appimage-run does not include gmp. To Reproduce Steps to reproduce the behavior: +x the appimage Expected behavior The app should run. Additional context I believe it is because of this commit: I fixed it on my end with: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I marked this as stale due to inactivity. →
not stale
Also affected:
as pointed out by t-paul, appimage specifically assumes GMP is provided by the system

fribidi p11-kit <ins> gmp </ins> # libraries not on the upstream include list, but nevertheless expected # by at least one appimage libtool.lib # for Synfigstudio


Question:
See e.g. or
I've been hoping for someone else to look at this one, but I expect I have to give it more visibility, hence this ticket.

sha256 = "03nislxccnbxld89giak2s8xa4mdbwscfxbdwhmw5qpvgz08dgwh"; }; <ins> # See <https://gitlab.com/apparmor/apparmor/-/issues/74> This and the # accompanying application in prePatchCommon should be removed in 2.13.5 gnumake43Patch = fetchpatch { url = "https://gitlab.com/apparmor/apparmor/-/merge_requests/465.patch"; name = "2-23-fix-build-with-make-4.3.patch"; sha256 = "0xw028iqp69j9mxv0kbwraplgkj5i5djdlgf0anpkc5cdbsf96r9"; }; </ins> prePatchCommon = '' <ins> patch -p1 < ${gnumake43Patch} chmod a+x ./common/list_capabilities.sh ./common/list_af_names.sh patchShebangs ./common/list_capabilities.sh ./common/list_af_names.sh </ins> substituteInPlace ./common/Make.rules --replace "/usr/bin/pod2man" "${buildPackages.perl}/bin/pod2man" substituteInPlace ./common/Make.rules --replace "/usr/bin/pod2html" "${buildPackages.perl}/bin/pod2html" substituteInPlace ./common/Make.rules --replace "/usr/include/linux/capability.h" "${linuxHeaders}/include/linux/capability.h"


Question:
The current version of qutebrowser (1.13.0, nixpkgs svn-revision: .) packaged in unstable fails to start with webkit backend. Forcing the backend in the resulting error dialog does nothing. To Reproduce Steps to reproduce the behavior: in qutebrowser Screenshots ! Notify maintainers
The qtwebkit backend was disabled in . Apparently at the time there was talk about dropping the backend but eventually they decided to keep it for a while. In any case here's what the current README says about it Soo, we could revert the commit but it seems it's going to be anyway. This is the reason, it looks like a variable that points to the qutebrowser executable is not actually resolved:
Thanks for the info regarding the readme and webkit. I'm pretty new to nixpks. Let me now if this would be a viable solution: and I'll make the PR. Also, where should I branch off of and what should be the target branch for my PR. It is the best I could come up with, because webkit and webengine depend on to different versions of qt5 so, we cannot easily have qutebrowser depend on both.
You can just revert the commit I mentioned: that should take care of also enabling qtwebkit by default, which is probably what you want. To make a PR you should target the master branch, also take a look at the .
Hmm... I don't really know, what to make of this part: in the current version it reads: and reverting just the other changes gives me build-errors.
Uhm, try something like this:
Now I get the original import error on starting qutebrowser, when I have set to . Maybe was the right solution after all, because that at least worked.

, mkDerivationWith, wrapQtAppsHook, wrapGAppsHook, qtbase, glib-networking , asciidoc, docbook_xml_dtd_45, docbook_xsl, libxml2 , libxslt, gst_all_1 ? null <del> , withPdfReader        ? true , withMediaPlayback    ? true </del> <ins> , withPdfReader      ? true , withMediaPlayback  ? true , backend            ? "webkit" </ins> }: assert withMediaPlayback -> gst_all_1 != null;


Question:
The current version of qutebrowser (1.13.0, nixpkgs svn-revision: .) packaged in unstable fails to start with webkit backend. Forcing the backend in the resulting error dialog does nothing. To Reproduce Steps to reproduce the behavior: in qutebrowser Screenshots ! Notify maintainers
The qtwebkit backend was disabled in . Apparently at the time there was talk about dropping the backend but eventually they decided to keep it for a while. In any case here's what the current README says about it Soo, we could revert the commit but it seems it's going to be anyway. This is the reason, it looks like a variable that points to the qutebrowser executable is not actually resolved:
Thanks for the info regarding the readme and webkit. I'm pretty new to nixpks. Let me now if this would be a viable solution: and I'll make the PR. Also, where should I branch off of and what should be the target branch for my PR. It is the best I could come up with, because webkit and webengine depend on to different versions of qt5 so, we cannot easily have qutebrowser depend on both.
You can just revert the commit I mentioned: that should take care of also enabling qtwebkit by default, which is probably what you want. To make a PR you should target the master branch, also take a look at the .
Hmm... I don't really know, what to make of this part: in the current version it reads: and reverting just the other changes gives me build-errors.
Uhm, try something like this:
Now I get the original import error on starting qutebrowser, when I have set to . Maybe was the right solution after all, because that at least worked.

stripRoot = false; }; <ins> backendPackage = if backend == "webengine" then python3Packages.pyqtwebengine else if backend == "webkit"    then python3Packages.pyqt5_with_qtwebkit else throw '' Unknown qutebrowser backend "${backend}". Valid choices are qtwebengine (recommended) or qtwebkit. ''; </ins> in mkDerivationWith python3Packages.buildPythonApplication rec { pname = "qutebrowser"; version = "1.13.0";


Question:
The current version of qutebrowser (1.13.0, nixpkgs svn-revision: .) packaged in unstable fails to start with webkit backend. Forcing the backend in the resulting error dialog does nothing. To Reproduce Steps to reproduce the behavior: in qutebrowser Screenshots ! Notify maintainers
The qtwebkit backend was disabled in . Apparently at the time there was talk about dropping the backend but eventually they decided to keep it for a while. In any case here's what the current README says about it Soo, we could revert the commit but it seems it's going to be anyway. This is the reason, it looks like a variable that points to the qutebrowser executable is not actually resolved:
Thanks for the info regarding the readme and webkit. I'm pretty new to nixpks. Let me now if this would be a viable solution: and I'll make the PR. Also, where should I branch off of and what should be the target branch for my PR. It is the best I could come up with, because webkit and webengine depend on to different versions of qt5 so, we cannot easily have qutebrowser depend on both.
You can just revert the commit I mentioned: that should take care of also enabling qtwebkit by default, which is probably what you want. To make a PR you should target the master branch, also take a look at the .
Hmm... I don't really know, what to make of this part: in the current version it reads: and reverting just the other changes gives me build-errors.
Uhm, try something like this:
Now I get the original import error on starting qutebrowser, when I have set to . Maybe was the right solution after all, because that at least worked.

]; propagatedBuildInputs = with python3Packages; [ <del> pyyaml pyqt5 pyqtwebengine jinja2 pygments </del> <ins> pyyaml backendPackage jinja2 pygments </ins> pypeg2 cssutils pyopengl attrs setuptools # scripts and userscripts libs tldextract beautifulsoup4 pyreadability pykeepass stem ]; <del> patches = [ ./fix-restart.patch ]; </del> <ins> patches = [ ./fix-restart.patch ]; </ins> dontWrapGApps = true; dontWrapQtApps = true;


Question:
The current version of qutebrowser (1.13.0, nixpkgs svn-revision: .) packaged in unstable fails to start with webkit backend. Forcing the backend in the resulting error dialog does nothing. To Reproduce Steps to reproduce the behavior: in qutebrowser Screenshots ! Notify maintainers
The qtwebkit backend was disabled in . Apparently at the time there was talk about dropping the backend but eventually they decided to keep it for a while. In any case here's what the current README says about it Soo, we could revert the commit but it seems it's going to be anyway. This is the reason, it looks like a variable that points to the qutebrowser executable is not actually resolved:
Thanks for the info regarding the readme and webkit. I'm pretty new to nixpks. Let me now if this would be a viable solution: and I'll make the PR. Also, where should I branch off of and what should be the target branch for my PR. It is the best I could come up with, because webkit and webengine depend on to different versions of qt5 so, we cannot easily have qutebrowser depend on both.
You can just revert the commit I mentioned: that should take care of also enabling qtwebkit by default, which is probably what you want. To make a PR you should target the master branch, also take a look at the .
Hmm... I don't really know, what to make of this part: in the current version it reads: and reverting just the other changes gives me build-errors.
Uhm, try something like this:
Now I get the original import error on starting qutebrowser, when I have set to . Maybe was the right solution after all, because that at least worked.

postFixup = '' wrapProgram $out/bin/qutebrowser  "''${gappsWrapperArgs[@]}"  <del> "''${qtWrapperArgs[@]}" </del> <ins> "''${qtWrapperArgs[@]}"  --add-flags '--backend ${backend}' </ins> ''; meta = with stdenv.lib; {


Question:
Dropbox does not work for me after the last update to version to 3.8.5 (commit ). The daemon starts, but no activity at all can be observed (it doesn't sync nor start the notification applet). If I start the old version that I still have in the store (3.6.9) it works. I run nixos on 32bit. I made several attempt: unlink/relink the computer from the dropbox site; restart with fresh ~/.dropbox and ~/Dropbox dirs; etc. Nothing works.
/cc author
does output anything?
also, which channel are you on? I just set up a nixos-unstable 32bit vm with dropbox 3.8.8 (not yet pushed) and it works fine
It's probably, because with 3.8.4, dropbox' qt dependency has been upgraded to 5.4, while current nixos-stable is still on 5.3 I bet you're on stable, right? Not sure if we should backport qt 5.4 to stable, or just downgrade dropbox to 3.6.9 and hope it keeps working till there is a new stable release.

# them with our own. let <del> version = "3.8.5"; </del> <ins> version = "3.6.9"; </ins> sha256 = { <del> "x86_64-linux" = "1r0wz2fsx2piasl04qsgwbl88bi0ajr0dm2swbslxwkf789vk18y"; "i686-linux" = "1dvfgp9dg3frhwmchwa6fyws4im9vgicchfsv0zzflvc7rm9fcig"; </del> <ins> "x86_64-linux" = "1i260mi40siwcx9b2sj4zwszxmj1l88mpmyqncsfa72k02jz22j3"; "i686-linux" = "0qqc8qbfaighbhjq9y22ka6n6apl8b6cr80a9rkpk2qsk99k8h1z"; </ins> }."${stdenv.system}" or (throw "system ${stdenv.system} not supported"); arch =


Question:
Describe the bug fails to build when attempting to cross-compile to aarch64 on : To Reproduce Expected behavior builds without error. Metadata nixpkgs Maintainer information:
I marked this as stale due to inactivity. →
Not stale - this issue still reproduces on current nixos-unstable ()

sha256 = "sha256-umY3wQfG26Okqnw+MCUnlwWTAyJ6MR/FHe5oe61KBh0="; }; <del> # The contents of this file comes from the Jamtop file from the # root of the ArgyllCMS distribution, rewritten to pick up Nixpkgs # library paths. When ArgyllCMS is updated, make sure that changes # in that file is reflected here. jamTop = writeText "argyllcms_jamtop" '' DESTDIR = "/" ; REFSUBDIR = "share/argyllcms" ; </del> <ins> nativeBuildInputs = [ jam unzip ]; </ins> <del> # Keep this DESTDIR anchored to Jamtop. PREFIX is used literally ANCHORED_PATH_VARS = DESTDIR ; </del> <ins> postPatch = lib.optionalString (stdenv.hostPlatform != stdenv.buildPlatform) '' substituteInPlace Jambase  --replace "-m64" "" ''; </ins> <del> # Tell standalone libraries that they are part of Argyll: DEFINES += ARGYLLCMS ; </del> <ins> preConfigure = let # The contents of this file comes from the Jamtop file from the # root of the ArgyllCMS distribution, rewritten to pick up Nixpkgs # library paths. When ArgyllCMS is updated, make sure that changes # in that file is reflected here. jamTop = writeText "argyllcms_jamtop" '' DESTDIR = "/" ; REFSUBDIR = "share/argyllcms" ; </ins> <del> # enable serial instruments & support USE_SERIAL = true ; </del> <ins> # Keep this DESTDIR anchored to Jamtop. PREFIX is used literally ANCHORED_PATH_VARS = DESTDIR ; </ins> <del> # enable fast serial instruments & support USE_FAST_SERIAL = true ;                # (Implicit in USE_SERIAL too) </del> <ins> # Tell standalone libraries that they are part of Argyll: DEFINES += ARGYLLCMS ; </ins> <del> # enable USB instruments & support USE_USB = true ; </del> <ins> # enable serial instruments & support USE_SERIAL = true ; </ins> <del> # enable dummy Demo Instrument (only if code is available) USE_DEMOINST = true ; </del> <ins> # enable fast serial instruments & support USE_FAST_SERIAL = true ;                # (Implicit in USE_SERIAL too) </ins> <del> # enable Video Test Patch Generator and 3DLUT device support # (V2.0.0 and above) USE_VTPGLUT = false ; </del> <ins> # enable USB instruments & support USE_USB = true ; </ins> <del> # enable Printer device support USE_PRINTER = false ; </del> <ins> # enable dummy Demo Instrument (only if code is available) USE_DEMOINST = true ; </ins> <del> # enable CMF Measurement device and accessory support (if present) USE_CMFM = false ; </del> <ins> # enable Video Test Patch Generator and 3DLUT device support # (V2.0.0 and above) USE_VTPGLUT = false ; </ins> <del> # Use ArgyllCMS version of libusb (deprecated - don't use) USE_LIBUSB = false ; </del> <ins> # enable Printer device support USE_PRINTER = false ; </ins> <del> # Compile in graph plotting code (Not fully implemented) USE_PLOT = true ;		# [true] </del> <ins> # enable CMF Measurement device and accessory support (if present) USE_CMFM = false ; </ins> <del> JPEGLIB = ; JPEGINC = ; HAVE_JPEG = true ; </del> <ins> # Use ArgyllCMS version of libusb (deprecated - don't use) USE_LIBUSB = false ; </ins> <del> TIFFLIB = ; TIFFINC = ; HAVE_TIFF = true ; </del> <ins> # Compile in graph plotting code (Not fully implemented) USE_PLOT = true ;		# [true] </ins> <del> PNGLIB = ; PNGINC = ; HAVE_PNG = true ; </del> <ins> JPEGLIB = ; JPEGINC = ; HAVE_JPEG = true ; </ins> <del> ZLIB = ; ZINC = ; HAVE_Z = true ; </del> <ins> TIFFLIB = ; TIFFINC = ; HAVE_TIFF = true ; </ins> <del> SSLLIB = ; SSLINC = ; HAVE_SSL = true ; </del> <ins> PNGLIB = ; PNGINC = ; HAVE_PNG = true ; </ins> <del> LINKFLAGS += ${lib.concatStringsSep " " (map (x: "-L${x}/lib") buildInputs)} -ldl -lrt -lX11 -lXext -lXxf86vm -lXinerama -lXrandr -lXau -lXdmcp -lXss -ljpeg -ltiff -lpng -lssl ; ''; </del> <ins> ZLIB = ; ZINC = ; HAVE_Z = true ; </ins> <del> nativeBuildInputs = [ jam unzip ]; </del> <ins> SSLLIB = ; SSLINC = ; HAVE_SSL = true ; </ins> <del> preConfigure = '' </del> <ins> LINKFLAGS += ${lib.concatStringsSep " " (map (x: "-L${x}/lib") buildInputs)} -ldl -lrt -lX11 -lXext -lXxf86vm -lXinerama -lXrandr -lXau -lXdmcp -lXss -ljpeg -ltiff -lpng -lssl ; ''; in '' </ins> cp ${jamTop} Jamtop substituteInPlace Makefile --replace "-j 3" "-j $NIX_BUILD_CORES" # Remove tiff, jpg and png to be sure the nixpkgs-provided ones are used rm -rf tiff jpg png <del> unset AR </del> <ins> export AR="$AR rusc" </ins> ''; buildInputs = [


Question:
Describe the bug fails to build when attempting to cross-compile to aarch64 on : To Reproduce Expected behavior builds without error. Metadata nixpkgs Maintainer information:
I marked this as stale due to inactivity. →
Not stale - this issue still reproduces on current nixos-unstable ()

mkdir -p $out/etc/udev/rules.d sed -i '/udev-acl/d' usb/55-Argyll.rules cp -v usb/55-Argyll.rules $out/etc/udev/rules.d/ <ins> sed -i -e 's/^CREATED .*/CREATED "'"$(date -d @$SOURCE_DATE_EPOCH)"'"/g' $out/share/argyllcms/RefMediumGamut.gam </ins> ''; meta = with lib; {


Question:
Mattermost fixed a security issue in 4.5.1:
cc
thanks for bringing this up. I'll create the necessary PRs.

in stdenv.mkDerivation rec { pname = "mattermost-desktop"; <del> version = "4.5.0"; </del> <ins> version = "4.5.2"; </ins> src = if stdenv.hostPlatform.system == "x86_64-linux" then fetchurl { url = "https://releases.mattermost.com/desktop/${version}/${pname}-${version}-linux-x64.tar.gz"; <del> sha256 = "1p44vxs7i9f15h4xjyr99g8x73qygv909a32lfkqip1fh8lk7sf4"; </del> <ins> sha256 = "0r9xmhzif1ia1m53yr59q6p3niyq3jv3vgv4703x68jmd46f91n6"; </ins> } else if stdenv.hostPlatform.system == "i686-linux" then fetchurl { url = "https://releases.mattermost.com/desktop/${version}/${pname}-${version}-linux-ia32.tar.gz"; <del> sha256 = "03pn853z2famqxcsrwayqb94pzghlpfb0qs2nfi8mc5zzsgcic7z"; </del> <ins> sha256 = "1h8lw06p3cqz9dkgbhfmzcrzjsir5cfhx28xm4zrmvkj4yfzbcnv"; </ins> } else throw "Mattermost-Desktop is not currently supported on ${stdenv.hostPlatform.system}";


Question:
Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in

fetch --experimental_distdir=${distDir} build --copt="$(echo $NIX_CFLAGS_COMPILE | sed -e 's/ /" --copt="/g')" build --host_copt="$(echo $NIX_CFLAGS_COMPILE | sed -e 's/ /" --host_copt="/g')" <ins> build --linkopt="$(echo $(< ${stdenv.cc}/nix-support/libcxx-ldflags) | sed -e 's/ /" --linkopt="/g')" build --host_linkopt="$(echo $(< ${stdenv.cc}/nix-support/libcxx-ldflags) | sed -e 's/ /" --host_linkopt="/g')" </ins> build --linkopt="-Wl,$(echo $NIX_LDFLAGS | sed -e 's/ /" --linkopt="-Wl,/g')" build --host_linkopt="-Wl,$(echo $NIX_LDFLAGS | sed -e 's/ /" --host_linkopt="-Wl,/g')" build --host_javabase='@local_jdk//:jdk'


Question:
Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in

fetch --distdir=${distDir} build --copt="$(echo $NIX_CFLAGS_COMPILE | sed -e 's/ /" --copt="/g')" build --host_copt="$(echo $NIX_CFLAGS_COMPILE | sed -e 's/ /" --host_copt="/g')" <ins> build --linkopt="$(echo $(< ${stdenv.cc}/nix-support/libcxx-ldflags) | sed -e 's/ /" --linkopt="/g')" build --host_linkopt="$(echo $(< ${stdenv.cc}/nix-support/libcxx-ldflags) | sed -e 's/ /" --host_linkopt="/g')" </ins> build --linkopt="-Wl,$(echo $NIX_LDFLAGS | sed -e 's/ /" --linkopt="-Wl,/g')" build --host_linkopt="-Wl,$(echo $NIX_LDFLAGS | sed -e 's/ /" --host_linkopt="-Wl,/g')" build --host_javabase='@local_jdk//:jdk'


Question:
Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in

# add the same environment vars to compile.sh sed -e "/$command $/a --copt="$(echo $NIX_CFLAGS_COMPILE | sed -e 's/ /" --copt="/g')" "  -e "/$command $/a --host_copt="$(echo $NIX_CFLAGS_COMPILE | sed -e 's/ /" --host_copt="/g')" "  <ins> -e "/$command $/a --linkopt="$(echo $(< ${stdenv.cc}/nix-support/libcxx-ldflags) | sed -e 's/ /" --linkopt="/g')" "  -e "/$command $/a --host_linkopt="$(echo $(< ${stdenv.cc}/nix-support/libcxx-ldflags) | sed -e 's/ /" --host_linkopt="/g')" "  </ins> -e "/$command $/a --linkopt="-Wl,$(echo $NIX_LDFLAGS | sed -e 's/ /" --linkopt="-Wl,/g')" "  -e "/$command $/a --host_linkopt="-Wl,$(echo $NIX_LDFLAGS | sed -e 's/ /" --host_linkopt="-Wl,/g')" "  -e "/$command $/a --host_javabase='@local_jdk//:jdk' "


Question:
Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in

openjdk_headless = openjdk8_headless; jdk8 = openjdk8; <ins> jdk8_headless = openjdk8_headless; </ins> jre8 = openjdk8.jre; jre8_headless = openjdk8_headless.jre;


Question:
Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in

bazel_0_26 = callPackage ../development/tools/build-managers/bazel/bazel_0_26 { inherit (darwin) cctools; inherit (darwin.apple_sdk.frameworks) CoreFoundation CoreServices Foundation; <del> buildJdk = jdk8; </del> <ins> buildJdk = jdk8_headless; </ins> buildJdkName = "jdk8"; runJdk = jdk11_headless; stdenv = if stdenv.cc.isClang then llvmPackages_6.stdenv else stdenv;


Question:
Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in

bazel_0_29 = callPackage ../development/tools/build-managers/bazel/bazel_0_29 { inherit (darwin) cctools; inherit (darwin.apple_sdk.frameworks) CoreFoundation CoreServices Foundation; <del> buildJdk = jdk8; </del> <ins> buildJdk = jdk8_headless; </ins> buildJdkName = "jdk8"; runJdk = jdk11_headless; stdenv = if stdenv.cc.isClang then llvmPackages_6.stdenv else stdenv;


Question:
Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in

bazel_1 = callPackage ../development/tools/build-managers/bazel/bazel_1 { inherit (darwin) cctools; inherit (darwin.apple_sdk.frameworks) CoreFoundation CoreServices Foundation; <del> buildJdk = jdk8; </del> <ins> buildJdk = jdk8_headless; </ins> buildJdkName = "jdk8"; runJdk = jdk11_headless; stdenv = if stdenv.cc.isClang then llvmPackages_6.stdenv else stdenv;


Question:
Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in

bazel_3 = callPackage ../development/tools/build-managers/bazel/bazel_3 { inherit (darwin) cctools; inherit (darwin.apple_sdk.frameworks) CoreFoundation CoreServices Foundation; <del> buildJdk = jdk8; </del> <ins> buildJdk = jdk8_headless; </ins> buildJdkName = "jdk8"; runJdk = jdk11_headless; stdenv = if stdenv.cc.isClang then llvmPackages_6.stdenv else stdenv;


Question: According to the 3.5 life-cycle () , the final release has already occurred and is now considered EOL. The jump from 3.5 to 3.6 has already happened in the majority of python packages and should not be a similar situation in which we had to extend python2's life long after its official EOL date.

### Interpreters <del> Versions 2.7, 3.5, 3.6, 3.7 and 3.8 of the CPython interpreter are available as respectively `python27`, `python35`, `python36`, `python37` and `python38`. The </del> <ins> Versions 2.7, 3.6, 3.7 and 3.8 of the CPython interpreter are available as respectively `python27`, `python36`, `python37` and `python38`. The </ins> aliases `python2` and `python3` correspond to respectively `python27` and `python38`. The default interpreter, `python`, maps to `python2`. The PyPy interpreters compatible with Python 2.7 and 3 are available as `pypy27` and


Question: According to the 3.5 life-cycle () , the final release has already occurred and is now considered EOL. The jump from 3.5 to 3.6 has already happened in the majority of python packages and should not be a similar situation in which we had to extend python2's life long after its official EOL date.

sets are * `pkgs.python27Packages` <del> * `pkgs.python35Packages` </del> * `pkgs.python36Packages` * `pkgs.python37Packages` <ins> * `pkgs.python38Packages` * `pkgs.python39Packages` </ins> * `pkgs.pypyPackages` and the aliases * `pkgs.python2Packages` pointing to `pkgs.python27Packages` <del> * `pkgs.python3Packages` pointing to `pkgs.python37Packages` </del> <ins> * `pkgs.python3Packages` pointing to `pkgs.python38Packages` </ins> * `pkgs.pythonPackages` pointing to `pkgs.python2Packages` #### `buildPythonPackage` function


Question: According to the 3.5 life-cycle () , the final release has already occurred and is now considered EOL. The jump from 3.5 to 3.6 has already happened in the majority of python packages and should not be a similar situation in which we had to extend python2's life long after its official EOL date.

inherit passthruFun; }; <del> python35 = callPackage ./cpython { self = python35; sourceVersion = { major = "3"; minor = "5"; patch = "9"; suffix = ""; }; sha256 = "0jdh9pvx6m6lfz2liwvvhn7vks7qrysqgwn517fkpxb77b33fjn2"; inherit (darwin) configd; inherit passthruFun; }; </del> python36 = callPackage ./cpython { self = python36; sourceVersion = {


Question: According to the 3.5 life-cycle () , the final release has already occurred and is now considered EOL. The jump from 3.5 to 3.6 has already happened in the majority of python packages and should not be a similar situation in which we had to extend python2's life long after its official EOL date.

<del> { lib , stdenv , buildPythonPackage , fetchPypi , pythonOlder # Build dependencies , glibcLocales # Test dependencies , nose , pygments # Runtime dependencies , jedi , decorator , pickleshare , traitlets , prompt_toolkit , pexpect , appnope , backcall , fetchpatch }: buildPythonPackage rec { pname = "ipython"; version = "7.9.0"; src = fetchPypi { inherit pname version; sha256 = "103jkw18z7fnwdal1mdbijjxi1fndzn31g887lmj7ddpf2r07lyz"; }; prePatch = lib.optionalString stdenv.isDarwin '' substituteInPlace setup.py --replace "'gnureadline'" " " ''; buildInputs = [ glibcLocales ]; checkInputs = [ nose pygments ]; propagatedBuildInputs = [ jedi decorator pickleshare traitlets prompt_toolkit pygments pexpect backcall ] ++ lib.optionals stdenv.isDarwin [appnope]; LC_ALL="en_US.UTF-8"; doCheck = false; # Circular dependency with ipykernel checkPhase = '' nosetests ''; pythonImportsCheck = [ "IPython" ]; meta = with lib; { description = "IPython: Productive Interactive Computing"; homepage = "http://ipython.org/"; license = licenses.bsd3; maintainers = with maintainers; [ bjornfor ]; }; } </del>


Question: According to the 3.5 life-cycle () , the final release has already occurred and is now considered EOL. The jump from 3.5 to 3.6 has already happened in the majority of python packages and should not be a similar situation in which we had to extend python2's life long after its official EOL date.

python2Full = python2.override{x11Support=true;}; python27Full = python27.override{x11Support=true;}; python3Full = python3.override{x11Support=true;}; <del> python35Full = python35.override{x11Support=true;}; </del> python36Full = python36.override{x11Support=true;}; python37Full = python37.override{x11Support=true;}; python38Full = python38.override{x11Support=true;};


Question: According to the 3.5 life-cycle () , the final release has already occurred and is now considered EOL. The jump from 3.5 to 3.6 has already happened in the majority of python packages and should not be a similar situation in which we had to extend python2's life long after its official EOL date.

python3Packages = python3.pkgs; pythonInterpreters = callPackage ./../development/interpreters/python {}; <del> inherit (pythonInterpreters) python27 python35 python36 python37 python38 python39 python3Minimal pypy27 pypy36; </del> <ins> inherit (pythonInterpreters) python27 python36 python37 python38 python39 python3Minimal pypy27 pypy36; </ins> # Python package sets. python27Packages = lib.hiPrioSet (recurseIntoAttrs python27.pkgs); <del> python35Packages = python35.pkgs; </del> python36Packages = python36.pkgs; python37Packages = recurseIntoAttrs python37.pkgs; python38Packages = recurseIntoAttrs python38.pkgs;


Question: According to the 3.5 life-cycle () , the final release has already occurred and is now considered EOL. The jump from 3.5 to 3.6 has already happened in the majority of python packages and should not be a similar situation in which we had to extend python2's life long after its official EOL date.

ipython = if isPy27 then callPackage ../development/python-modules/ipython/5.nix { } <del> else if isPy35 then callPackage ../development/python-modules/ipython/7.9.nix { } </del> else callPackage ../development/python-modules/ipython { };


Question: According to the 3.5 life-cycle () , the final release has already occurred and is now considered EOL. The jump from 3.5 to 3.6 has already happened in the majority of python packages and should not be a similar situation in which we had to extend python2's life long after its official EOL date.

) super.ocaml-ng; python27 = super.python27.override { static = true; }; <del> python35 = super.python35.override { static = true; }; </del> python36 = super.python36.override { static = true; }; python37 = super.python37.override { static = true; }; python38 = super.python38.override { static = true; };


Question:
I am building nixos against the latest head and I get this warning message when running my Makefile command in my configuration It seems like it warns you about the obsolete option even after you've removed it from your configuration.
That's because it's used internally
It should be fine now, I believe. Thanks.

{stdenv, fetchurl}: stdenv.mkDerivation rec { <del> name = "ncompress-4.2.4.3"; </del> <ins> name = "ncompress-4.2.4.4"; </ins> builder = ./builder.sh;


Question:
I am building nixos against the latest head and I get this warning message when running my Makefile command in my configuration It seems like it warns you about the obsolete option even after you've removed it from your configuration.
That's because it's used internally
It should be fine now, I believe. Thanks.

src = fetchurl { url = "mirror://sourceforge/project/ncompress/${name}.tar.gz"; <del> sha256 = "1y44ixc1w2vfvj1lm4dkcljlwv882ynrvm5i6l0lg1gf883j246l"; </del> <ins> sha256 = "0yjiwv1hwb253x3m6r1dq2k7m5c9nz0ib2j7fnm3hark7y6s42xh"; </ins> }; meta = {


Question:
Describe the bug After fixing the the evaluation of the in I realized that it occasionally breaks with the following error: node1: output: PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. --- 10.0.0.2 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4085ms error: Traceback (most recent call last): File "/nix/store/b6m9jif1kib2dqc6fy2ym31vzs4f7hhd-nixos-test-", line 830, in run_tests exec(tests, globals()) File "<string", line 1, in <moduleFile "<string", line 8, in <moduleFile "/nix/store/b6m9jif1kib2dqc6fy2ym31vzs4f7hhd-nixos-test-", line 363, in succeed raise Exception( Exception: command failed (exit code 1) cleaning up killing node1 (pid 6) killing node2 (pid 18) error: --- Error
nix-build error: --- Error --- nix-daemon builder for '/nix/store/g14icd814yvak6syxjimgc6g8y459ki1-vm-test-run-' failed with exit code 1 Please note that the functionality isn't broken per se, on I managed to successfully build it as . Notify maintainers cc
I'm guessing that having the pings be would resolve this, unless we want to assert that actually ensures that the peers are fully connected?
No it doesn't, I already tried this out, the command times out then. I guess that sometimes the isn't configured properly.
The issue is coming from the private key (/run/wg-priv), for some reason, it looks like networkd is sometimes trying to load it to wireguard before the systemd tmpfile gets linked.

virtualisation.vlans = [ 1 ]; environment.systemPackages = with pkgs; [ wireguard-tools ]; boot.extraModulePackages = [ config.boot.kernelPackages.wireguard ]; <del> systemd.tmpfiles.rules = [ "f /run/wg_priv 0640 root systemd-network - ${privk}" ]; </del> systemd.network = { enable = true; netdevs = { "90-wg0" = { netdevConfig = { Kind = "wireguard"; Name = "wg0"; }; wireguardConfig = { <del> PrivateKeyFile = "/run/wg_priv"; </del> <ins> # NOTE: we're storing the wireguard private key in the #       store for this test. Do not do this in the real #       world. Keep in mind the nix store is #       world-readable. PrivateKeyFile = pkgs.writeText "wg0-priv" privk; </ins> ListenPort = 51820; FirewallMark = 42; };


Question:
Describe the bug The last several Hydra trunk-combined runs have been blocked by (among other problems) a , which was recently back(?) to release-combined in (). When I run the test locally it sometimes succeeds and sometimes hangs forever. To Reproduce Steps to reproduce the behavior: it succeeded, clear the result with (is there a better way to do that?) and try again. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(anders): nixpkgs: Maintainer information:
We have a lot of channel blockers currently, so I recommend to also purpose revert this one. Though it sounds like it's only with issues, so perhaps comment it linking to this issue. We can always re-add it.

(onFullSupported "nixos.tests.networking.networkd.dhcpSimple") (onFullSupported "nixos.tests.networking.networkd.link") (onFullSupported "nixos.tests.networking.networkd.loopback") <del> (onFullSupported "nixos.tests.networking.networkd.macvlan") </del> <ins> # Fails nondeterministically (https://github.com/NixOS/nixpkgs/issues/96709) #(onFullSupported "nixos.tests.networking.networkd.macvlan") </ins> (onFullSupported "nixos.tests.networking.networkd.privacy") (onFullSupported "nixos.tests.networking.networkd.routes") (onFullSupported "nixos.tests.networking.networkd.sit")


Question: , CVSSv3=7.7 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) CVSSv3=7.1 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) Scanned versions: nixos-unstable: . Cc Cc

buildGoPackage rec { pname = "etcd"; <del> version = "3.3.22"; </del> <ins> version = "3.3.25"; </ins> goPackagePath = "github.com/coreos/etcd";


Question: , CVSSv3=7.7 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) CVSSv3=7.1 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) Scanned versions: nixos-unstable: . Cc Cc

owner = "etcd-io"; repo = "etcd"; rev = "v${version}"; <del> sha256 = "1rd390qfx9k20j9gh1wp1g9ygc571f2kv1dg2wvqij3kwydhymcj"; </del> <ins> sha256 = "10cyy6jr2xzmla5yyn850cv323ixrk70fjpk8lxjjjvy0ffmb6hj"; </ins> }; buildPhase = ''


Question: , CVSSv3=7.7 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) CVSSv3=7.1 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) Scanned versions: nixos-unstable: . Cc Cc

install -Dm755 bin/* bin/functional/cmd/* -t $out/bin ''; <del> passthru.tests = with nixosTests; { etcd = etcd; etcd-cluster = etcd-cluster; }; </del> <ins> passthru.tests = { inherit (nixosTests) etcd etcd-cluster; }; </ins> meta = with lib; { description = "Distributed reliable key-value store for the most critical data of a distributed system";