jiebi/CodeConvo huggingface dataset:
Change:
inherit (lib) mkOption types; <ins> podmanPackage = (pkgs.podman.override { inherit (cfg) extraPackages; }); </ins> # Provides a fake "docker" binary mapping to podman <del> dockerCompat = pkgs.runCommandNoCC "${pkgs.podman.pname}-docker-compat-${pkgs.podman.version}" { </del> <ins> dockerCompat = pkgs.runCommandNoCC "${podmanPackage.pname}-docker-compat-${podmanPackage.version}" { </ins> outputs = [ "out" "bin" "man" ]; <del> inherit (pkgs.podman) meta; </del> <ins> inherit (podmanPackage) meta; </ins> } '' mkdir $out mkdir -p $bin/bin <del> ln -s ${pkgs.podman.bin}/bin/podman $bin/bin/docker </del> <ins> ln -s ${podmanPackage.bin}/bin/podman $bin/bin/docker </ins> mkdir -p $man/share/man/man1 <del> for f in ${pkgs.podman.man}/share/man/man1/*; do </del> <ins> for f in ${podmanPackage.man}/share/man/man1/*; do </ins> basename=$(basename $f | sed s/podman/docker/g) ln -s $f $man/share/man/man1/$basename done

Discussion:
Describe the bug Podman's packaging isn't following the spirit of Nix, as far as I can tell. It seems to pull in a bunch of run-time executable dependencies via PATH resolution instead of build-time resolution. To Reproduce nix-shell -p podman --run podman based on the module, it looks like several run-time executables are referenced through PATH resolution instead of build-time pinning: Expected behavior Nix's build products should have stable references to their run-time dependencies whenever possible. Given podman's rootless container support, I doubly expected to give a usable podman.
Maintainer cc
Hmm im not sure how I feel about this. Podman is agnostic of container runtime for example. So it not having a path to either runc or crun is a feature. But conmon should probably be referenced by nix path yes. And utillinux too. We could perhaps default to runc runtime and let people opt to crun?
check out this PR from
I see the issue here. We could also discuss if it generally would make sense to have a build-time config feature for podman. Having strong defaults without configuration could be achieved that way for NixOS, too.
Is this expected to work without registry and policy files in ?
I would like it to, and it sounds like there is upstream work to make that possible.
This already works with rootless podman if you have the appropriate subuib/subgids set up. If is merged will work out of the box on NixOS.
Change:
, libwacom , libxml2 , libxslt <del> , magpie </del> , meson , modemmanager , networkmanager

Discussion:
Budgie desktop stopped working a few months ago on because gsettings schema supplied by Budgie is missing settings which was recently to . This causes to crash during startup making Budgie DE setup unusable. budgie-desktop from . .
Are you using Budgie alongside another desktop? Otherwise LightDM is the preferred choice for Budgie, but I will still look into this.
Oh, I didn't know that. When I switched from gnome to budgie, I kept and everything worked, so I kept it. I can confirm that if I use , everything works.
Change:
bunyan-rs = callPackage ../development/tools/bunyan-rs { }; <ins> calcure = callPackage ../applications/misc/calcure { }; </ins> callaudiod = callPackage ../applications/audio/callaudiod { }; calls = callPackage ../applications/networking/calls { };

Discussion:
Project description Modern TUI calendar and task manager with customizable interface. Manages your events and tasks, displays birthdays from your , and can import events and tasks from and . Metadata homepage URL: source URL: license: MIT platforms: linux, macos, windows
Can you please test the linked PR?
Builds and launches fine on nixos. Thank you :)
Change:
(self: super: { aiofiles = super.aiofiles.overridePythonAttrs (oldAttrs: rec { pname = "aiofiles"; <del> version = "0.5.0"; </del> <ins> version = "0.7.0"; </ins> src = fetchFromGitHub { owner = "Tinche"; repo = pname; rev = "v${version}"; <del> sha256 = "17bsg2x5r0q6jy74hajnbp717pvbf752w0wgih6pbb4hdvfg5lcf"; </del> <ins> sha256 = "sha256-njQ7eRYJO+dUrwO5pZwKHXn9nVSGYcEhwhs3x5BMc28="; </ins> }; doCheck = false; });

Discussion:
On nixos-unstable, the package does not install: is installed No maintainer but pinging who last touched Please run and paste the result.
was updated to 4.0.1 a while back. is pinning most of it's dependencies thus the issue. Looks like that could need an update (available 2.2.18, upstream 2.2.27).
So I can build the upgraded package with the following: But it doesn't look right. I guess we shouldn't blindly replace pinned versions with incompatible versions. How does nixpkgs usually deals with this?
Change:
${cfg.promptInit} ${bashCompletion} <ins> ${lsColors} </ins> ${bashAliases} ${cfge.interactiveShellInit}

Discussion:
As in the title. At the moment ls colors orphaned symbolic links just as normal symbolic links per default. As symbolic links are really ubiquitous in nix or nixos, is it a good a idea to change that default setting? (From reading the comments in the source, the idea is not following symbolic links, if it isn't really necessary, to avoid the work. Coloring orphaned links different per default, all the effort not to follow symbolic links, wouldn't be used usually.) It's a one line change, I could happily provide a pr (or is it mr) for. In a directory without the files and . ln -s a b LS_COLORS="" ls --color=always
I like this idea. After playing with it a little bit I went ahead and created a PR, since I think it deserves more than a 1-liner. There are bound to be those who want it toggleable.
Change:
bonzomatic = callPackage ../applications/editors/bonzomatic { }; <del> brackets = callPackage ../applications/editors/brackets { gconf = gnome2.GConf; }; </del> brave = callPackage ../applications/networking/browsers/brave { }; break-time = callPackage ../applications/misc/break-time { };

Discussion:
, CVSSv3=9.8 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.

Current version of brackets in nixpkgs is while the latest release is as of Jun 18, 2018.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Change:
Restart = "on-failure"; RestartSec = 2; TasksMax = "infinity"; <ins> LoadCredential = lib.mapAttrsToList (key: value: "${key}:${value}") cfg.credentials; </ins> } (mkIf cfg.enableDocker { SupplementaryGroups = "docker"; # space-separated string

Discussion:
I currently generate an HCL file with my consul token and nomad server encryption key. When dropping privileges, it requires me keeping this HCL file world readable. Having support for (easy to override as-is) and (not overridable due to type requirement on ) would allow systemd to copy secrets somewhere readable by nomad. to contain a root:root 0400 file. = true = true (potentially more settings for a minimum viable nomad config) Nomad reads secrets from extra settings HCL file, starts successfully. Add any other context about the problem here. No official maintainers, but may have ideas. I spent some time experimenting, root of the problem is that we need to pass "-config ${CREDENTIALSDIRECTORY}" in ExecStart, along with those files in the LoadCredentials systemd stanza. I'm not sure if there is an idiomatic way to do this in Nix.
Could you test ? Make sure I have solved your problem.
Will take a look, thanks!
Change:
<ins> { lib, buildNpmPackage, fetchFromGitHub, nix-update-script, callPackage, testers, xunit-viewer, }: let version = "10.6.1"; in buildNpmPackage { pname = "xunit-viewer"; inherit version; src = fetchFromGitHub { owner = "lukejpreston"; repo = "xunit-viewer"; rev = "v${version}"; hash = "sha256-n9k1Z/wofExG6k/BxtkU8M+Lo3XdCgCh8VFj9jcwL1Q="; }; npmDepsHash = "sha256-6PV0+G1gzUWUjOfwRtVeALVFFiwkCAB33yB9W0PCGfc="; passthru.updateScript = nix-update-script { }; passthru.tests = { version = testers.testVersion { package = xunit-viewer; version = "unknown"; # broken, but at least it runs }; example = callPackage ./test/example.nix { }; }; meta = { description = "View your xunit results using JavaScript"; homepage = "https://lukejpreston.github.io/xunit-viewer"; license = with lib.licenses; [ mit ]; maintainers = with lib.maintainers; [ pluiedev ]; platforms = lib.platforms.all; }; } </ins>

Discussion:
Project description xunit-viewer is an node package that formats JUnit/xunit test results into HTML reports. Metadata homepage URL: source URL: license: mit platforms: - no native dependencies
Change:
npmDepsHash = "sha256-rwzyKaCW3LAOqw6BEu8DLS0Ad5hB6cH1OnjWzbSEgVI="; nativeBuildInputs = [ <del> python3 </del> <ins> python311 </ins> ] ++ lib.optionals stdenv.isDarwin [ darwin.cctools xcbuild.xcrun

Discussion:
Steps to reproduce the behavior: bitwarden-cli on aarch64-linux using nixos-unstable () Builds on x86_64-linux. Downgrading python to 3.11 can fix it. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
, enableAPICheck ? false , enableVMAssertions ? false , useSystemMalloc ? false <ins> # Upstream generates randomized string id's by default for security reasons # https://github.com/LuaJIT/LuaJIT/issues/626. Deterministic string id's should # never be needed for correctness (that should be fixed in the lua code), # but may be helpful when you want to embed jit-compiled raw lua blobs in # binaries that you want to be reproducible. , deterministicStringIds ? false </ins> , luaAttr ? "luajit_${lib.versions.major version}_${lib.versions.minor version}" } @ inputs: assert enableJITDebugModule -> enableJIT;

Discussion:
Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . 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. You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: Looks like symbol ordering differences:
Change:
{file = "boto-2.49.0.tar.gz", hash = "sha256:ea0d3b40a2d852767be77ca343b58a9e3a4b00d9db440efb8da74b4e58025e5a"}, ] boto3 = [ <del> {file = "boto3-1.24.6-py3-none-any.whl", hash = "sha256:1c13d555172cf88eb645af2429e4a7f42be85e365d6ffc110c952a556d3f8808"}, {file = "boto3-1.24.6.tar.gz", hash = "sha256:4af6a8bc5110b5f9d2fbd00a3c110e4c4cc36fae78d05afa354831f5789e363b"}, </del> <ins> {file = "boto3-1.24.16-py3-none-any.whl", hash = "sha256:2c6f7e4103d41ca07d6b934a6612e4b9a2666eae36e8289f88726868534b8de2"}, {file = "boto3-1.24.16.tar.gz", hash = "sha256:422c000ff2ee5226e89fe427a9c4c09db095d69c179a3bcc3cfba37cbc5e787e"}, </ins> ] botocore = [ <del> {file = "botocore-1.27.6-py3-none-any.whl", hash = "sha256:eeebe304161db6828413dc358ea80ece52f4ddbc8ecde4dd58978d5861a09293"}, {file = "botocore-1.27.6.tar.gz", hash = "sha256:97c909a6ec5ad421573c18ae67fc6ea4232502cd30cffaf03bfcb584d9df652d"}, </del> <ins> {file = "botocore-1.27.16-py3-none-any.whl", hash = "sha256:f117d59899d21beeb200130d7af2090a8112d702a06e2c2794ef576bcea36773"}, {file = "botocore-1.27.16.tar.gz", hash = "sha256:b3b9710902f675a11f5bfd46afda770150530876ae6541d099584462bf949fd1"}, </ins> ] certifi = [ <del> {file = "certifi-2022.5.18.1-py3-none-any.whl", hash = "sha256:f1d53542ee8cbedbe2118b5686372fb33c297fcd6379b050cca0ef13a597382a"}, {file = "certifi-2022.5.18.1.tar.gz", hash = "sha256:9c5705e395cd70084351dd8ad5c41e65655e08ce46f2ec9cf6c2c08390f71eb7"}, </del> <ins> {file = "certifi-2022.6.15-py3-none-any.whl", hash = "sha256:fe86415d55e84719d75f8b69414f6438ac3547d2078ab91b67e779ef69378412"}, {file = "certifi-2022.6.15.tar.gz", hash = "sha256:84c85a9078b11105f04f3036a9482ae10e4621616db313fe045dd24743a0820d"}, </ins> ] cffi = [ {file = "cffi-1.15.0-cp27-cp27m-macosx_10_9_x86_64.whl", hash = "sha256:c2502a1a03b6312837279c8c1bd3ebedf6c12c4228ddbad40912d671ccc8a962"},

Discussion:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)
Change:
argv = list(cmdline) -        if argv[0].find("python")<0: -            argv.insert(0, "python%i.%i" % (sys.version_info.major, sys.version_info.minor)) <del> return systemd_run_wrap(mode, argv, options.systemd_run_args) </del> <ins> return systemd_run_wrap(mode, argv, options.systemd_run_args, user=getuid()!=0) </ins> configure_env(options.env) configure_logging(options, mode)

Discussion:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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 <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR. Priorities Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I've got a branch that would close this issue and update xpra to 5.0.3, the UI currently works as expected and a connection over SSH is possible however I've encountered an issue running and . The error output is similar to what can be found in some other python applications. I'll look into patching this and see if I can push this further.
Change:
or (throw "cannot bootstrap GHC on this platform")); nativeBuildInputs = [ perl ]; <del> buildInputs = stdenv.lib.optionals (stdenv.targetPlatform.isAarch32 || stdenv.targetPlatform.isAarch64) [ llvm ]; </del> <ins> propagatedBuildInputs = stdenv.lib.optionals useLLVM [ llvmPackages.llvm ]; </ins> # Cannot patchelf beforehand due to relative RPATHs that anticipate # the final install location/

Discussion:
On current master (). Fails with See also the . Additional context The hscolour derivation mentioned here does not contain in its . It seems sufficient to make be a propagated build input for , after doing so I can build ghc itself. There's a lot of Metadata Maintainer information:
Can you send a PR fixing this?
Done, see
[ ] port to
Since this issue was opened the situation has changed. There's still no ghc on aarch64, but now it fails due to [the lack of aarch64 support][] in (aka ). [the lack of aarch64 support]:
After PR the default ghc builds for aarch64 (, ATM only in branch).
Change:
}; }; <ins> postFixup = '' # Cannot use wrapGAppsHook'due to a dependency cycle wrapProgram $out/libexec/at-spi-bus-launcher  --prefix GIO_EXTRA_MODULES : "${stdenv.lib.getLib gnome3.dconf}/lib/gio/modules"  --prefix XDG_DATA_DIRS : ${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name} ''; </ins> meta = with stdenv.lib; { description = "Assistive Technology Service Provider Interface protocol definitions and daemon for D-Bus"; homepage = https://gitlab.gnome.org/GNOME/at-spi2-core;

Discussion:
It seems that all nix expressions for gnome3 applications need revision regarding environment variables wrapping. For instance on my unstable NixOS system I have on on my configuration. All of them (except , which I have already fixed), when run outside of gnome3, are giving error messages like I think they may be fixed by replacing uses of to explicitly fix binaries, by , which automatically fixes them wrapping environment variables. EDIT: In some cases it also needs to add a dependency on .
Related: (also includes a few fixes)
cc
I think the last instances of this were fixed by
In the core GNOME, I only came across two not wrapped executables. from package and from . Unfortunately the former cannot be wrapped due to depending on .
Change:
checkConfigError "The option .multiple. is defined multiple times" config.multiple ./raw.nix checkConfigOutput "bar" config.priorities ./raw.nix <ins> # Test that types.optionType merges types correctly checkConfigOutput '^10$' config.theOption.int ./optionTypeMerging.nix checkConfigOutput '^"hello"$' config.theOption.str ./optionTypeMerging.nix # Test that types.optionType correctly annotates option locations checkConfigError 'The option .theOption.nested. in .other.nix. is already declared in .optionTypeFile.nix.' config.theOption.nested ./optionTypeFile.nix </ins> cat <<EOF ====== module tests ====== $pass Pass

Discussion:
See the : the options aren't declared by any file (it's actually , but that's stripped at some point). I think this is most likely because they are declared inside a : but I don't know the module system well enough to troubleshoot this. This was causing the unstable channel import to because of an which should be fixed by This is an issue of the module system, so pinging
fixes this, thanks for the report!
Change:
sha256 = "1qss4q5df3nsydsbggb7gg50bn0kdxq5wn8riqm9zwkiq6a4bifg"; }; nativeBuildInputs = [ docbook_xsl docbook_xsl_ns ModuleBuild ]; <del> propagatedBuildInputs = [ TextWrapI18N LocaleGettext TermReadKey SGMLSpm UnicodeLineBreak PodParser YAMLTiny ]; </del> <ins> propagatedBuildInputs = [ TextWrapI18N LocaleGettext SGMLSpm UnicodeLineBreak PodParser YAMLTiny ]; # TODO: TermReadKey was temporarily removed from propagatedBuildInputs to unfreeze the build </ins> buildInputs = [ gettext libxslt glibcLocales docbook_xml_dtd_412 docbook_sgml_dtd_41 texlive.combined.scheme-basic opensp ]; LC_ALL = "en_US.UTF-8"; SGML_CATALOG_FILES = "${docbook_xml_dtd_412}/xml/dtd/docbook/catalog.xml";

Discussion:
Describe the bug A clear and concise description of what the bug is. when doing nixos-rebuild build -I nixos-config=./nix- -I nixpkgs=/mnt/vmpool/jkarlson/repos/nixpkgs po4a-0.55 build gets stuck in a busyloop in command perl po4a --previous --no-translations --msgid-bugs-address --package-name po4a --package-version 0.55 This dependency is caused by enabling = true; To Reproduce Steps to reproduce the behavior: master or release-19.09 to nixpkgs path attached config nixos-rebuild build -I nixos-config=./nix- -I nixpkgs=/path/to/nixpkgs Expected behavior build to complete Additional context Installing po4a as a normal package just fetches the binary cache, I am not sure where this package actually builds. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(jkarlson): nixpkgs: Maintainer information: yaml attribute: po4a module:
The config in question.
I have exactly the same problem on due to being enabled on my system (which has as a build dependency). Based on a command i see in ps it is exactly the same version of po4a:
Here is inlined config that posted above
Problem still exists on latest channel. cc you in to this as an original package maintainer, maybe you have some ideas on why this is happening.
Problem still persists sadly :( Not sure what possible solutions to this would be. Any help on this is appreciated.
One can apparently just remove Po4a from sssd build inputs, not sure what we would be missing this way.
It's used at build time to produce the documentation in all available languages
Yeah, maybe that would be a good temporary solution. Having working package beats the lacking documentation I think.
I solved this on my system by dropping po4a from list of dependencies for sssd: My overrides: :
since you asked (between the lines) whether there was more hacky but shorter way to do this. As Po4a is only used as buildInputs, you can feed it whatever you want without touching sssd files.
Oh did not think about that, pretty clever! Will use this instead.
Change:
tags = [ "netgo" ]; <del> vendorHash = "sha256-Wn/9vIyw99BudhhTnoN81Np70VInV6uo7Sru64nhPgk="; </del> <ins> proxyVendor = true; vendorHash = "sha256-9w44gpaB2C/F7hTImjdeabWVgTU5AA/7OSJmAqayrzU="; </ins> # TODO investigate why some config tests are failing doCheck = !(stdenv.isDarwin && stdenv.isAarch64);

Discussion:
Steps to reproduce the behavior: k9s in unstable with nix-darwin My 28.2 works fine but it's fetched from binary cache and the one who bumped this Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I don't have nix-darwin, is there a way to test this without a Mac?
Hi, I don`t remember seeing status for Darwin machines on PR, as it takes a little bit of time, returning to the PR ofborg raises checksum errors: Could you please try on ? If I remember correctly, this helps if the code is generating platform specific hashs. Also, if you can, trying to bring back tests (which do not run for darwin/aarch64) would be cool, as I do not have either available as HW to test.
For comparasion, 28.2 PR
Hi, but sorry I'm new in Nix and the easier way I can think of is to add this to my configuration: What I get is basically the same: Should I try forking nixpkgs, modify it and point my flake input to my fork?
Sorry I missed the CI failure on the update PR. I'm always wondering why those aren't red/blocking. I'll have a aarch64-darwin available in some hours.
Hi, I actually put this in my home-manager programs. Maybe it can be tested in this way?
the override doesn't seem to be applied, it would change the . Might be easiest to checkout nixpkgs, apply the change and run
You and me both, AFAIK Darwin is a second-class citizen with scarce infrastructure and maintainers.
I succeeded after both adding proxyVendor and updating vendorHash So this is a package maintenance bug rather than a platform bug?
Yes. please take a look at
Change:
<ins> { lib , fetchFromGitHub , wayland }: { version = "unstable-2023-03-16"; src = fetchFromGitHub { owner = "hyprwm"; repo = "xdg-desktop-portal-hyprland"; rev = "85f49f4d6c9c398428117e9bdb588f53f09e52e0"; hash = "sha256-qed+BV0NBt1egGCBEM7d5MiZJevQb8jd1WybfFM53Ak="; }; meta = with lib; { description = "xdg-desktop-portal backend for Hyprland"; homepage = "https://github.com/hyprwm/xdg-desktop-portal-hyprland"; license = licenses.mit; maintainers = with maintainers; [ fufexan ]; platforms = wayland.meta.platforms; }; } </ins>

Discussion:
Project description A wlroots-compatible Wayland color picker that does not suck. Metadata homepage URL: source URL: license: platforms: linux Just because you made available on NixOS, I wanted to point you on hyprpicker, too - if you're interested to have a look into this(?)
I'll take a look into packaging this.
Change:
ROOT="$(dirname "$(readlink -f "$0")")" NIXPKGS_ROOT="$ROOT/../../../.." <del> NIX_DRV="$ROOT/default.nix" </del> COMMON_FILE="$ROOT/common.nix"

Discussion:
Package name: Latest released version: 1.34.0 <!-- Search your package here: --- Current version on the unstable channel: 1.27.0 Current version on the stable/release channel: 1.27.0 <!-- 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 <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.
Note: the update script isn't working on my system, I assume that's why has not uploaded any updates.
Ill take a look tomorrow :)