jiebi/CodeConvo huggingface dataset:
Change:
<ins> import ./make-test-python.nix ({ lib, pkgs, ... }: { name = "freshrss"; meta.maintainers = with lib.maintainers; [ mattchrist ]; nodes.machine = { pkgs, ... }: { services.freshrss = { enable = true; baseUrl = "http://localhost"; authType = "none"; }; }; testScript = '' machine.wait_for_unit("multi-user.target") machine.wait_for_open_port(80) response = machine.succeed("curl -vvv -s http://127.0.0.1:80/i/") assert '<title>Main stream · FreshRSS</title>' in response, "FreshRSS stream page didn't load successfully" ''; }) </ins>

Discussion:
Unable to use freshrss. It returns the error . Try http://localhost, be redirected to http://localhost/i/?rid=, see the error It should run without errors. thank you all for maintaining this module Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I think this issue is happening because the default user isn't being created by the 'freshrss-config' service when authType none is specified. I'll work on a PR to fix this shortly. In the meanwhile, I think a workaround would be to start freshrss with authType form configured once, to initialize the default user, then switching to authType none afterwards.
Change:
buildInputs = [ libxml2 <ins> zlib </ins> ]; dontUseCmakeConfigure = true;

Discussion:
Steps to reproduce the behavior: to update the system with nixos-rebuild failed with message error: builder for '/nix/store/dq3k8nz8ass49r942swi73z09a20m53r-julia-' failed with exit code 2; last 10 log lines: For full logs, run 'nix log /nix/store/dq3k8nz8ass49r942swi73z09a20m53r-julia-'. Please run and paste the result.
Change:
''; sourceProvenance = with sourceTypes; [ fromSource <del> binaryBytecode  # deps </del> <ins> binaryBytecode # deps </ins> ]; license = licenses.asl20; platforms = platforms.unix;

Discussion:
Package name: jadx Latest released version: 1.5.0 Current version on the unstable channel: 1.4.7 Current version on the stable/release channel: 1.4.7 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers affects 1.4.7 - I would generally bump this myself but the packaging appears to have quirks that look like they need adaptation. Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<ins> # Test Traefik as a reverse proxy of a local web service # and a Docker container. import ./make-test-python.nix ({ pkgs, ... }: { name = "traefik"; meta = with pkgs.stdenv.lib.maintainers; { maintainers = [ joko ]; }; nodes = { client = { config, pkgs, ... }: { environment.systemPackages = [ pkgs.curl ]; }; traefik = { config, pkgs, ... }: { docker-containers.nginx = { extraDockerOptions = [ "-l" "traefik.enable=true" "-l" "traefik.http.routers.nginx.entrypoints=web" "-l" "traefik.http.routers.nginx.rule=Host(`nginx.traefik.test`)" ]; image = "nginx-container"; imageFile = pkgs.dockerTools.examples.nginx; }; networking.firewall.allowedTCPPorts = [ 80 ]; services.traefik = { enable = true; dynamicConfigOptions = { http.routers.simplehttp = { rule = "Host(`simplehttp.traefik.test`)"; entryPoints = [ "web" ]; service = "simplehttp"; }; http.services.simplehttp = { loadBalancer.servers = [{ url = "http://127.0.0.1:8000"; }]; }; }; staticConfigOptions = { global = { checkNewVersion = false; sendAnonymousUsage = false; }; entryPoints.web.address = ":80"; providers.docker.exposedByDefault = false; }; }; systemd.services.simplehttp = { script = "${pkgs.python3}/bin/python -m http.server 8000"; serviceConfig.Type = "simple"; wantedBy = [ "multi-user.target" ]; }; users.users.traefik.extraGroups = [ "docker" ]; }; }; testScript = '' start_all() traefik.wait_for_unit("docker-nginx.service") traefik.wait_until_succeeds("docker ps | grep nginx-container") traefik.wait_for_unit("simplehttp.service") traefik.wait_for_unit("traefik.service") traefik.wait_for_open_port(80) traefik.wait_for_unit("multi-user.target") client.wait_for_unit("multi-user.target") with subtest("Check that a container can be reached via Traefik"): assert "Hello from NGINX" in client.succeed( "curl -sSf -H Host:nginx.traefik.test http://traefik/" ) with subtest("Check that dynamic configuration works"): assert "Directory listing for " in client.succeed( "curl -sSf -H Host:simplehttp.traefik.test http://traefik/" ) ''; }) </ins>

Discussion:
Project description Traefik is a microservice oriented reverse proxy written in Go. It configures itself by container labels from docker/other provider or from text files. It does TLS termination and can fetch certs from let's encrypt automatically. A nixOS module to add configuration to the file backend (similar to the nginx ones) seems easy to implement. Traefik 1.0 is currently packaged (, ) Traefik 2.0 is NOT backwards compatible A package for 2.0 (not source built) has been written up by Metadata homepage URL: source URL: license: MIT platforms: linux, darwin, freebsd, openbsd, windows
Change:
!allowUnfree && !allowUnfreePredicate attrs; <del> allowInsecureDefaultPredicate = x: builtins.elem (getName x) (config.permittedInsecurePackages or []); </del> <ins> allowInsecureDefaultPredicate = x: builtins.elem (getNameWithVersion x) (config.permittedInsecurePackages or []); </ins> allowInsecurePredicate = x: (config.allowInsecurePredicate or allowInsecureDefaultPredicate) x; hasAllowedInsecure = attrs:

Discussion:
When running it fails due to an insecure package. To resolve this the output of recommends adding to the file (in my case for electron) This is incorrect as the correct line that should be must contain the package name and ver sion instead of just the package name (eg: instead of ) Steps to reproduce the behavior: while having an insecure package the instructions in the output The output must specify instead of in the sample code. This is the current (wrong) full output
Change:
nativeBuildInputs = [ makeWrapper gawk pkgconfig ]; buildInputs = [ readline libtool ]; <del> propagatedBuildInputs = [ gmp ]; patches = [ ./cpp-4.5.patch ]; </del> <ins> propagatedBuildInputs = [ gmp # XXX: These ones aren't normally needed here, but `libguile*.la' has '-l' # flags for them without corresponding '-L' flags. Adding them here will add # the needed `-L' flags.  As for why the `.la' file lacks the `-L' flags, # see below. libtool ]; </ins> <del> postInstall = '' wrapProgram $out/bin/guile-snarf --prefix PATH : "${gawk}/bin" ''; preBuild = '' sed -e '/lt_dlinit/a  lt_dladdsearchdir("'$out/lib'");' -i libguile/dynl.c ''; </del> <ins> patches = [ ./cpp-4.5.patch ]; </ins> # Guile needs patching to preset results for the configure tests # about pthreads, which work only in native builds.

Discussion:
I attempted to bisect, but so many of the possible commits would have spent hours building that I wasn't able to narrow it down.
Reverting seems to fix the build here. I'm not sure which part of the commit is causing the issue in the first place, and since the commit is supposed to fix some issues a straight-up revert is likely a wrong solution. Perhaps will be able to help?
Seems like instead of reverting the commit adding back to of guile fixes this build failure as well. If is any indication it does indeed seem to be required for linking to guile: ( is part of libtool)
Hmm ok I made it non-propagated to be consistent, because the newer ones just looked better packaged
You mean the newer guile packages? They all have in their .
Oh I see how I screwed this up. Changing the PR to make all the fixes happen in each.
Change:
# `recurseIntoAttrs` for sake of hydra, not nix-env tests = recurseIntoAttrs { cc-wrapper = callPackage ../test/cc-wrapper { }; <del> cc-wrapper-clang = callPackage ../test/cc-wrapper { stdenv = clangStdenv; }; cc-wrapper-libcxx = callPackage ../test/cc-wrapper { stdenv = libcxxStdenv; }; </del> <ins> cc-wrapper-clang = callPackage ../test/cc-wrapper { stdenv = llvmPackages.stdenv; }; cc-wrapper-libcxx = callPackage ../test/cc-wrapper { stdenv = llvmPackages.libcxxStdenv; }; cc-wrapper-clang-39 = callPackage ../test/cc-wrapper { stdenv = llvmPackages_39.stdenv; }; cc-wrapper-libcxx-39 = callPackage ../test/cc-wrapper { stdenv = llvmPackages_39.libcxxStdenv; }; </ins> stdenv-inputs = callPackage ../test/stdenv-inputs { }; macOSSierraShared = callPackage ../test/macos-sierra-shared {};

Discussion:
In Nixpkgs 17.09, 3.9 cannot find libstdc++ headers: This does work correctly with Clang 4.0 in 17.09, or Clang 3.9 in 17.03. Setting shows that the cc-wrapper is not adding the appropriate flags pointing to libstdc++ in gcc. See above. System: NixOS 17.03 Nix version: 1.12pre Nixpkgs version: 17.09beta285. Sandboxing enabled: no
According to git-bisect, one of the following commits is causing the issue (all by
Hmm, was supposed to have fixed this, but I guess only fixed 4.0. any idea?
Really thought I already applied those changes to the other versions, must have forgotten to push or something.
Ah I see now---I should have noticed when reviewing that. While we're at it, maybe we should inject it in cc-wrapper instead of stdenv? This mirrors and keeps slimmer.
Change:
, lua , openal , pkg-config <ins> , strip-nondeterminism </ins> , stdenv , zip , zlib

Discussion:
Building this package multiple times does not yield bit-by-bit identical results, complicating the detection of Continuous Integration (CI) breaches. For more information on this issue, visit . Fixing bit-by-bit reproducibility also has additional advantages, such as avoiding hard-to-reproduce bugs, making content-addressed storage more effective and reducing rebuilds in such systems. This step will build the package. Specific arguments are passed to the command to keep the build artifacts so we can compare them in case of differences. Execute the following command: Or using the new command line style: If the previous command completes successfully, no differences were found and there's nothing to do, builds are reproducible. If it terminates with the error message error: derivation '&lt;X' may not be deterministic: output '&lt;Y' differs from '&lt;Z'diffoscope to investigate the discrepancies between the two build outputs. You may need to add the option to ignore files and directories metadata (e.g. timestamp) differences. To examine the build log, use: Or with the new command line style: After checking out and building , output of was: So it seems to just be some timestamps in the archive . ᵗʰᶦˢ ᵗᵉᵐᵖˡᵃᵗᵉ ᶦˢ ʷᵉᶦʳᵈ Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Recently, I learned, that there's a tool called , which can help get rid of timestamps in archives. I'll try to come up with a fix using that.
Change:
in mkIf conf.enable { warnings = conf.warnings or []; <del> users.users = (mkIf (conf.user == "${name}-exporter" && !enableDynamicUser) { "${name}-exporter" = { description = '' Prometheus ${name} exporter service user ''; isSystemUser = true; inherit (conf) group; }; </del> <ins> users.users."${name}-exporter" = (mkIf (conf.user == "${name}-exporter" && !enableDynamicUser) { description = "Prometheus ${name} exporter service user"; isSystemUser = true; inherit (conf) group; </ins> }); users.groups = (mkIf (conf.group == "${name}-exporter" && !enableDynamicUser) { "${name}-exporter" = {};

Discussion:
Describe the bug Enabling prometheus-node-exporter with writes one or both of these lines to : and causes NixOS to show To Reproduce Steps to reproduce the behavior: NixOS master, set in configuration bad line in and warning from update-users- Additional context I believe this regressed in . Metadata system: host os: multi-user?: sandbox: version: Maintainer information: cc
Change:
]; postPatch = '' <ins> (cd tools && ln -s ../../clang-tools-extra extra) </ins> sed -i -e 's/DriverArgs.hasArg(options::OPT_nostdlibinc)/true/'  -e 's/Args.hasArg(options::OPT_nostdlibinc)/true/'  lib/Driver/ToolChains/*.cpp

Discussion:
The wrapper script created by clang-tools is broken again. Previous issue: clang-tools should be built correctly so that it (, etc.) can be started/used. I briefly looked at the llvmPackages v12 and v13 Nix expressions () since the last clang-tools fix was in the v12 package. There are enough changes that I'm unable to mentally cherry-pick the fix for v12 onto v13. I'm not sure why/when v13 diverged enough from v12 to break the package.
This seems to fix it for me, care to give it a try? I think we'd need to do the same for llvm git as well:
Thanks! That seems to work. Will you make a PR? Suggestion: change to to fail as early as possible if "tools" is missing.
And yes, we'd need it for too (good catch!).
I'm listed as the maintainer of , but unfortunately I no longer use it and no longer have time to maintain it. Would someone here be willing to take over maintainership for this package?
yes, I'd love to ; one sec, I'll prepare a merge request
Can we get this fix backported to 21.11? Not sure what the policy is for mass-rebuilds of a release branch. If that's acceptable I can prepare the PR.
Sure, I think we can make that happen. Each release has its own staging branch for mass rebuilds, and this is a regression bugfix so I think it qualifies for a backport.
This issue should be closed, it works now.
Change:
"Inconsolata" = "02rar6g3zbbpxxxz37v7d5qzafn59bhp04iv3wk16kqxy0havgx5"; "InconsolataGo" = "0nx6j3v2fvhdw3ygmz65zwlj6zwrkpmf59wfxirpzkcqqsdh4zwl"; "InconsolataLGC" = "00s2051fz3k6jnsfmnlqnd2cghr9sj2pddi5gpid1i5x006rig7a"; <ins> "IntelOneMono" = "02cynzrpn93b1kmi21p60lhdai6rppmm3m1f872kvf08damc1660"; </ins> "Iosevka" = "1byrmfbsqi06fsy958364jy694dnm7a7pcjsv64w6mwfsi5vjn1r"; "IosevkaTerm" = "1k65jfa0c7c6pvns7vfcxcfc3i1qcr6wg16qafbp9zggabbvl7aa"; "JetBrainsMono" = "0mbzvfl36a6mgb2dnjf8n3kkm28sz0xhv7s5lww141wpgj5jb4a9";

Discussion:
Package name: Latest released version: 3.0.2 Current version on the unstable channel: 3.0.2 Current version on the stable/release channel: 3.0.1 Notify maintainers This issue isn't to update nerd fonts necessarily, but currently the Intel One Mono font, is missing from the font list in unstable. Could this be please? Thanks :)
Interesting... Last time when we ran the script these fonts weren't there. They probably these fonts to the release after we updated the version here. Your approval is welcome at .
Looks good to me :+1: thanks for getting on it so quickly!
Change:
{ lib, stdenv, buildPythonPackage, fetchPypi, isPy27, python <del> , IOKit </del> <ins> , CoreFoundation, IOKit </ins> , pytestCheckHook , mock , unittest2

Discussion:
For a while now, some routines have been segfaulting on darwin. This has become more problematic recently because newer versions of make a call to , which pretty robustly segfaults on darwin. Packages that use in their tests are failing as a result. e.g. 's own tests are of course disabled because they have proven to be so problematic. We've opened some upstream issues for these problems (, ), but I'm increasingly starting to feel these are Our Bugs. The next step is probably to do some proper debugging on these segfaults, but I personally lack the motivation to learn darwin's weird debugging ecosystem (give me gdb and ELF anyday), so instead I'm documenting my findings here. Steps to reproduce the behavior: on darwin (tested x86_64, macos 10.15) When I use a pip-installed version on the same machine it succeeds: Maintainer information:
I can’t reproduce on aarch64-darwin running macOS 12.0.1. I tried both the aarch64 and x86_64 builds of Python. (Not saying this isn’t a problem, but it may be that it’s dependent on the macOS version being run.)
~That is an interesting data point, because I'm quite certain that our uses a much newer SDK version.~ Hold on, I think we've miscommunicated, the pip method works for me too - I suppose listing it as the expected behaviour is unclear. Let me reword.
Does the first of my two snippets fail on your system?
Sorry, yeah. I also tested that first but only posted the second results. Here’s what I get with the first snippet.
I just tested the x86_64-darwin binaries on my aarch64-darwin system and got the crash.
Ok so it is still potentially SDK-version-related.
This sounds very similar to the problem in . I wonder if it's related.
I had a look at this when it was mentioned on matrix. From what I can tell the crash occurs as soon as psutil tries to interact with CoreFoundation types returned from querying the system. I did some printf style debugging by adding calls to , and all I could get was a crash. I suspect it's related to mixing and matching system CoreFoundation with swift-corefoundation built from source.

I haven't gotten to the bottom of the issue yet, but if psutil is explicitly linked with system CoreFoundation[1], then it seems to work. that forces the the linker to use system corefoundation. <details<summarycomparison</summaryWithout: With </details
how to resolve the issue?
Not sure if related I am getting this error
I also got same error on our CI (linux armd64) with . Is there a workaround for this?
Closing because of which is supposed to address this. And I can't reproduce on x86_64-darwin.
Change:
<ins> # This file was generated by https://github.com/kamilchm/go2nix v1.2.1 [ { goPackagePath = "github.com/cihub/seelog"; fetch = { type = "git"; url = "https://github.com/cihub/seelog"; rev = "f561c5e57575bb1e0a2167028b7339b3a8d16fb4"; sha256 = "0r3228hvgljgpaggj6b9mvxfsizfw25q2c1761wsvcif8gz49cvl"; }; } { goPackagePath = "github.com/shirou/gopsutil"; fetch = { type = "git"; url = "https://github.com/shirou/gopsutil"; rev = "eeb1d38d69593f121e060d24d17f7b1f0936b203"; sha256 = "01qsznk599225gf4pld7p2m30p61y77mvzhrs6raxpk6wf7icp4w"; }; } { goPackagePath = "golang.org/x/sys"; fetch = { type = "git"; url = "https://go.googlesource.com/sys"; rev = "77b0e4315053a57ed2962443614bdb28db152054"; sha256 = "1024gcv1b40i2rgvpgyw2hgy1k5g7473pn29yavwysj37m1rrplp"; }; } ] </ins>

Discussion:
Expected output: empty gohai can be found here: This holds for nixpkgs master.
I've submitted to fix this issue. We've worked around it until this is released by adding the derivation to our NixOS configuration repository and adding it to the unit's path, like so: NixOS will merge that option together with the already existing derivations on the unit's path, so it doesn't break the existing configuration. We've been running this change on a dozen or so live-servers and it works fine.
pull request was merged.
The fix is now in 18.03 :)
Change:
version = "11.4.2" url = "https://developer.download.nvidia.com/compute/cuda/11.4.2/local_installers/cuda_11.4.2_470.57.02_linux.run" sha256 = "sha256-u9h8oOkT+DdFSnljZ0c1E83e9VUILk2G7Zo4ZZzIHwo=" <del> gcc = "gcc10" # can bump to 11 along with stdenv.cc </del> <ins> gcc = "gcc11" </ins> ["11.5"] version = "11.5.0" url = "https://developer.download.nvidia.com/compute/cuda/11.5.0/local_installers/cuda_11.5.0_495.29.05_linux.run" sha256 = "sha256-rgoWk9lJfPPYHmlIlD43lGNpANtxyY1Y7v2sr38aHkw=" <del> gcc = "gcc10" # can bump to 11 along with stdenv.cc </del> <ins> gcc = "gcc11" </ins> ["11.6"] version = "11.6.1" url = "https://developer.download.nvidia.com/compute/cuda/11.6.1/local_installers/cuda_11.6.1_510.47.03_linux.run" sha256 = "sha256-qyGa/OALdCABEyaYZvv/derQN7z8I1UagzjCaEyYTX4=" <del> gcc = "gcc10" # can bump to 11 along with stdenv.cc </del> <ins> gcc = "gcc11" </ins>

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking python3Packages.jaxlibWithCuda. python3Packages.jaxlibWithCuda maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
I'm observing this error with many more packages (e.g. ). I'd expect it would've been introduced introduced elsewhere than in openscad commit?
I just bisected a similar bug (dm-tree failure) to
I'm not sure what to do about this... It seems like the kinda of thing people won't want to rollback, but it's also breaking a loooooot of things. cc
Can't reproduce, no build failure on my end. Hydra also has a cached built copy.
I think it's only the version that's failing
I'll see what happens if we bump in
Hopefully it is only a gcc mismatch issue.
RE: Ok, actually tensorflow and jaxlib are still pinned to and override to , so they're all pulling in . Idk about unpinning tensorflow, but I'm pretty sure we should be safe to switch jaxlib to the default cuda packages
As far as the error message goes it seems like it wants LLVM clang rather than GNU g++.
That's a good point. I think we should unpin jax from needing to use the same versions as TF. This seemed like a good idea at the time (I advocated for it), but it's proven to be a PITA since then. TF's version constraints are just so outdated. would you be opposed? I suspect that this was caused by the GCC bump, but I'm not 100% certain yet. I'm currently bisecting a different failure, but once that's done I'll try to debug this further!
Unpinning jax from the old cudaPackages and bumping the new cuda packages to gcc11 I get no more missing symbols, but I fail with:
Thanks for taking a stab at that Just to confirm: is that error within glibc or is it indicating a misuse of glibc APIs?
would you mind the derivation that you've been using? I'm curious to reproduce
good catch, the error was from: I was trying to build with updating and removing for jaxlib and jaxlib-build
Created an issue upstream:
Change:
inherit (lib) mkOption types; <del> # Once https://github.com/NixOS/nixpkgs/pull/75584 is merged we can use the TOML generator toTOML = name: value: pkgs.runCommandNoCC name { nativeBuildInputs = [ pkgs.remarshal ]; value = builtins.toJSON value; passAsFile = [ "value" ]; } '' json2toml "$valuePath" "$out" ''; </del> <ins> toml = pkgs.formats.toml { }; </ins> in { meta = {

Discussion:
Describe the bug creates a defect as the block is defined two times. To Reproduce Steps to reproduce the behavior: Enable and Expected behavior and should be merged to one block. Additional context I'm on zfs. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(plumps): channels(root): nixpkgs: Maintainer information:
I have a PR up to fix this