jiebi/CodeConvo huggingface dataset:
Code change:
CPPFLAGS = concatStringsSep " " (map (p: "-I${getDev p}/include") buildInputs); LDFLAGS = concatStringsSep " " (map (p: "-L${getLib p}/lib") buildInputs); LIBS = "${optionalString (!stdenv.isDarwin) "-lcrypt"} ${optionalString (ncurses != null) "-lncurses"}"; <del> NIX_LDFLAGS = optionalString (stdenv.isLinux && !stdenv.hostPlatform.isMusl) "-lgcc_s" + optionalString stdenv.hostPlatform.isMusl "-lgcc_eh"; </del> <ins> NIX_LDFLAGS = lib.optionalString stdenv.cc.isGNU ({ "glibc" = "-lgcc_s"; "musl" = "-lgcc_eh"; }."${stdenv.hostPlatform.libc}" or ""); </ins> # Determinism: We fix the hashes of str, bytes and datetime objects. PYTHONHASHSEED=0;

Related discussion:
text: The Linux stdenv sets But that flag is specific to GNU strip, and LLVM's strip will fail if passed it. Conveniently, we silence all errors from stripping, so this has gone unnoticed until now: I noticed this while trying to fix . One of the reasons it doesn't work is that it has in , and strip should be removing that reference but isn't. What I'm not sure about here is the best way to fix this. There's nothing platform-specific about this option, so it shouldn't live in the Linux stdenv. (Other platforms like NetBSD use GNU binutils by default.) Ideally it would be a conditional in the strip setup hook, but we don't really have a bash equivalent to . So where (in Nix) should we check this and set the variable? cc
With what we have at the moment, I can only think of hacky workarounds like checking if ends in . However such an approach (and even checking ) is actually incorrect: and don't have to be matched, e. g. with as linker and GNU bintools is quite common actually. Looking at prior art in nixpkgs, I'm quite convinced that the cleanest solution for now would be to bite the bullet and extend to also wrap . In fact, we already seem to have a strip wrapper for darwin.
Hmm, I don't like the idea of globally adding a flag only to remove it again in a wrapper. Another idea I had was to do this in the definition of make- — the hardening flags are precedent for doing manipulation of environment variables for setup hooks in there. We could add an isGNU attribute to the possible values of , and use that? I don't much like this idea either, but I like it better than adding the flag globally and then wrapping to remove it. What do you think?
Since this flag is unconditionally in general, I think we can just remove it from the linux hook and instead add it in the binutils-wrapper. This should also solve the issue of this being binutils-specific and not linux-specific AIUI.
Oh, you mean wrap GNU binutils' strip to add this flag? That sounds fine to me.
If I understand correctly this is now done:
Code change:
<ins> { lib , rustPlatform , fetchCrate }: rustPlatform.buildRustPackage rec { pname = "hayagriva"; version = "0.3.0"; src = fetchCrate { inherit pname version; hash = "sha256-zp7YfMmp16YRWNcOf5aVt1vXnL+23+DyFeFn7Gow7wM="; }; cargoHash = "sha256-jsVd4vyST563HiXvqCfiZ2oUhNXF4E8Y2HBLl5AtvRw="; buildFeatures = [ "cli" ]; meta = with lib; { description = "Work with references: Literature database management, storage, and citation formatting"; homepage = "https://github.com/typst/hayagriva"; changelog = "https://github.com/typst/hayagriva/releases/tag/v${version}"; license = with licenses; [ asl20 mit ]; maintainers = with maintainers; [ figsoda ]; }; } </ins>

Related discussion:
text: Project description Convert bibtex file to yaml which typst needed. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: mit, apache platforms: unix, linux, darwin, ...
Code change:
, alsa-lib , libjack2 , libusb1 <del> , udev </del> , libsndfile , vulkanSupport ? true , vulkan-headers

Related discussion:
text: Steps to reproduce the behavior: for the pipewire package, e.g.: building it This can be fixed by either making sure that flag controls the Meson option in addtion to the , or by exposing a new option to control the directly. ping let me know which of the options above you guys prefer and I can open up a PR to fix as well. <!-- 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]:
Can we just remove that option instead?
Sorry do you mean set the to always be false or completely remove the as an option? Because I prefer the abilitiy to turn as many unnecessary dependencies as practically possible on my system (better stability and security).
Remove the option, yes, because we can't realistically maintain the exponential explosion of possible flag combinations.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I made two PRs: and Feel free to pick whichever PR looks better to you
arg removed in
How much maintenance burden does this actually cause? IMO the package options are one of Nixpkgs strengths (one of the things that attracted me, after I stopped working on Homebrew because package options started to be removed entirely), and they're critical for people working on systems where size matters.
To expand a bit, I don't think that package maintainers should generally be expected to support all combinations of options, but I also don't think they should block people who want to from doing so. Just having the flags there shouldn't cause any problems for package maintainers that don't want to maintain the flags, and it's fine IMO to respond to issues about flags not working by asking people to adopt the flag and send a patch.
No one's blocking people from overriding. It's just a bad idea to have some flags we haven't even looked at in months and pretend we support them by including them in the expression. Or in other words, keeping the flags is shipping broken code if people don't maintain them.
The enableSystemd flag had clearly been looked at recently, because there was a commit from me fixing it, and yet it was removed anyway.
Code change:
}; nativeBuildInputs = [ pkgconfig ]; <del> buildInputs = [ openssl_1_0_2 libpcap ]; </del> <ins> buildInputs = [ openssl libpcap ]; </ins> # Mongodb incorrectly names all of their binaries main # Let's work around this with our own installer

Related discussion:
text: Upstream , but we still have many packages depending on it. I know of no issues since the last release, so I'm not marking it as vulnerable yet, but the dependents would better start migrating in advance. Stable: it's unclear to me what we do about these in 19.09, but perhaps there won't be any notable vulnerabilities before 19.09 support ends :-) 1.0.2 is the default in 19.03, but we don't support that anymore.
List of files:
I think we should mark it vulnerable. Other EOL packages have been marked vulnerable because of the EOL before, e.g. Firefox, and if there’s any package we should be extra-careful with, its OpenSSL.
I bumped it to fix the last CVE minutes before opening this ticket, so I was obviously biased against marking it immediately ;-)
BTW, it's still a decision to make, as there's surely some LTS distro that will keep shipping 1.0.2 for some time, so patching the worst probably won't be too difficult. I'm personally not willing to invest significant time into it, though :-)
Best way to motivate somebody to volunteer is to mark it as insecure. ;)
OK, I think the we've given enough time and now we should press on a bit:
Code change:
<del> { lib, fetchFromGitHub, python3, cdparanoia, cdrdao, flac , sox, accuraterip-checksum, libsndfile, util-linux, substituteAll }: </del> <ins> { lib , python3 , fetchFromGitHub , libcdio-paranoia , cdrdao , libsndfile , flac , sox , util-linux }: </ins> <del> python3.pkgs.buildPythonApplication rec { </del> <ins> let bins = [ libcdio-paranoia cdrdao flac sox util-linux ]; in python3.pkgs.buildPythonApplication rec { </ins> pname = "whipper"; version = "0.10.0";

Related discussion:
text: Describe the bug throws an error when attempting to generate the musicbrainz disc id: Notify maintainers recently updated the package in listed as maintainer Maintainer information:
Code change:
type = types.str; default = "/var/lib/gitolite"; description = '' <del> Gitolite home directory (used to store all the repositories). </del> <ins> The gitolite home directory used to store all repositories. If left as the default value this directory will automatically be created before the gitolite server starts, otherwise the sysadmin is responsible for ensuring the directory exists with appropriate ownership and permissions. </ins> ''; };

Related discussion:
text: Describe the bug My server uses an encrypted filesystem /data that I have to mount manually after reboot. Gitolite is configured to use /data/gitolite. I have configured gitolite-init to only run once /data is mounted. Mounting of /data always fails, as gitolite uses to generate directories and thus the mountpoint is not empty. Manual cleanup is required every time. Expected behavior Gitolite should create its directories in gitolite-init.service. Additional context systemd-tmpfiles-setup.service runs before the system is fully initialized, so I cannot delay that service. 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'll try to address this in the next few days.
Code change:
owner = "devicetree-org"; repo = "dt-schema"; rev = "refs/tags/v${version}"; <del> hash = "sha256-wwlXIM/eO3dII/qQpkAGLT3/15rBLi7ZiNtqYFf7Li4="; </del> <ins> sha256 = "sha256-+wF6WdonZrkZEnlq/P6QeT3X7CMinxbapLa7q0t2zUc="; </ins> }; <ins> patches = [ # Change name of pylibfdt to libfdt ./fix_libfdt_name.patch ]; </ins> SETUPTOOLS_SCM_PRETEND_VERSION = version; nativeBuildInputs = [

Related discussion:
text: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: dt-schema <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 2022.1 desired version: 2022.12 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
A new version is out: Should I just update this and my PR to make use of this new version?
Code change:
EOF ipfs --local config --json "${concatStringsSep "." path}" "$value" '') <del> cfg.extraConfig) </del> <ins> ({ Addresses.API = cfg.apiAddress; Addresses.Gateway = cfg.gatewayAddress; Addresses.Swarm = cfg.swarmAddress; } // cfg.extraConfig)) </ins> ); serviceConfig = { ExecStart = "${wrapped}/bin/ipfs daemon ${ipfsFlags}";

Related discussion:
text: default: cc Until then, just edit manually.
Remember you can do this too: = [ "/ip4/0.0.0.0/tcp/4001" "/ip6/::/tcp/4001" ]; It seems reasonable to have this default, however, since the nixos module has no way of getting the daemon to reset options when the user removes an explicit option from Incidentally, some config needs special handling, since it can't be set without re-initializing the leveldb, etc. I don't like the idea of having to duplicate every default setting into a , but I guess there's no other way until the ipfs devs make the daemon's config less stateful. I would prefer they move this type of runtime config into command-line args whose absence indicates that defaults should be used. Perhaps we should file that upstream.
Code change:
<ins> { stdenv , lib , fetchurl , qt4 , SDL }: stdenv.mkDerivation rec { pname = "tworld2"; version = "2.2.0"; src = fetchurl { url = "https://tw2.bitbusters.club/downloads/tworld-${version}-src.tar.gz"; sha256 = "sha256:1y55v2shk2xxcds7bdwdjaq9lka31sgdp2469zqnvldchwbvcb2i"; }; buildInputs = [ qt4 SDL ]; enableParallelBuilding = true; postConfigure = '' echo "#define COMPILE_TIME "$(date -ud "@$SOURCE_DATE_EPOCH" '+%Y %b %e %T %Z')"" >comptime.h ''; makeFlags = [ "bindir=${placeholder "out"}/bin" "sharedir=${placeholder "out"}/share" "mandir=${placeholder "out"}/share/man/en" ]; postInstall = '' mkdir -p $out/share/doc/${pname} cp COPYING README docs/tworld2.html $out/share/doc/${pname} mkdir $out/share/icons cp tworld.ico tworld2.ico $out/share/icons ''; meta = with lib; { description = "Tile World 2: Tile World is a reimplementation of the game Chip's Challenge"; homepage = "https://tw2.bitbusters.club/"; license = licenses.gpl2Plus; platforms = platforms.linux; maintainers = with maintainers; [ drperceptron ]; }; } </ins>

Related discussion:
text: Project description Tile World 2 Metadata homepage URL: source URL: license: gpl2+ platforms: linux
Code change:
fetchfossil = callPackage ../build-support/fetchfossil { }; <del> fetchgit = callPackage ../build-support/fetchgit { </del> <ins> fetchgit = (callPackage ../build-support/fetchgit { </ins> git = buildPackages.gitMinimal; cacert = buildPackages.cacert; git-lfs = buildPackages.git-lfs; <ins> }) // { # fetchgit is a function, so we use // instead of passthru. tests = callPackages ../build-support/fetchgit/tests.nix {}; </ins> }; fetchgitLocal = callPackage ../build-support/fetchgitlocal { };

Related discussion:
text: Fetchers are hard to test because when the output sha is verified, Nix won't download it again. This leads to confusion and PRs that are effectively untested because the others do not realize that they need to remove the store path before testing. Examples: Steps to reproduce the behavior: a fetcher -build the fetcher -build "success" but the fetcher is broken a PR effort The fetcher runs every time. This is expected but not realistic, because Nix can not guess what to re-fetch. Instead, we can make fetcher testing easier by adding fetcher tests following the pattern: So this uses IFD which is probably ok for ofborg? Regarding ; instead of somewhere, we'll have to use to set on the fetchers because they're functions. The salt may need to be passed externally in case of pure evaluation. We could make it a Nixpkgs parameter that defaults to . <!-- 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. Maintainer information:
Workaround: Use followed by
Or we can just put the salt in the parameter. Nix isn't clever enough to find same-hash renames in the store :)
And the salt can be derived from the unsalted drv path, which is exactly what we want. See
Code change:
stdenv.mkDerivation rec { version = "5.2.0"; pname = "octave"; src = fetchurl { url = "mirror://gnu/octave/${pname}-${version}.tar.gz"; sha256 = "1qcmcpsq1lfka19fxzvxjwjhg113c39a9a0x8plkhvwdqyrn5sig"; }; <del> buildInputs = [ gfortran readline ncurses perl flex texinfo qhull graphicsmagick pcre pkgconfig fltk zlib curl openblas libsndfile fftw fftwSinglePrec portaudio qrupdate arpack libwebp gl2ps ] ++ (stdenv.lib.optional (qt != null) qt) ++ (stdenv.lib.optional (qscintilla != null) qscintilla) ++ (stdenv.lib.optional (ghostscript != null) ghostscript) ++ (stdenv.lib.optional (llvm != null) llvm) ++ (stdenv.lib.optional (hdf5 != null) hdf5) ++ (stdenv.lib.optional (glpk != null) glpk) ++ (stdenv.lib.optional (suitesparse != null) suitesparse) ++ (stdenv.lib.optional (jdk != null) jdk) ++ (stdenv.lib.optional (gnuplot != null) gnuplot) ++ (stdenv.lib.optional (python != null) python) ++ (stdenv.lib.optionals (!stdenv.isDarwin) [ libGL libGLU libX11 ]) ; # makeinfo is required by Octave at runtime to display help prePatch = '' substituteInPlace libinterp/corefcn/help.cc  --replace 'Vmakeinfo_program = "makeinfo"'  'Vmakeinfo_program = "${texinfo}/bin/makeinfo"' ''; </del> <ins> buildInputs = [ readline ncurses perl flex qhull graphicsmagick pcre fltk zlib curl openblas libsndfile fftw fftwSinglePrec portaudio qrupdate arpack libwebp gl2ps ] ++ (stdenv.lib.optionals enableQt [ qtbase qtsvg qscintilla ]) ++ (stdenv.lib.optional (ghostscript != null) ghostscript) ++ (stdenv.lib.optional (hdf5 != null) hdf5) ++ (stdenv.lib.optional (glpk != null) glpk) ++ (stdenv.lib.optional (suitesparse != null) suitesparse) ++ (stdenv.lib.optional (jdk != null) jdk) ++ (stdenv.lib.optional (sundials_2 != null) sundials_2) ++ (stdenv.lib.optional (gnuplot != null) gnuplot) ++ (stdenv.lib.optional (python != null) python) ++ (stdenv.lib.optionals (!stdenv.isDarwin) [ libGL libGLU libX11 ]) ; nativeBuildInputs = [ pkgconfig gfortran # Listed here as well because it's outputs are split fftw fftwSinglePrec texinfo ] ++ (stdenv.lib.optional (sundials_2 != null) sundials_2) ++ (stdenv.lib.optional enableJIT llvm) ++ (stdenv.lib.optionals enableQt [ qtscript qttools ]) ; </ins> doCheck = !stdenv.isDarwin;

Related discussion:
text: I'm trying to build octave with QT5 and with GUI (of course, when I try to build it with GUI, right?). Unfortunately, after the build: Apply this patch: and then system: host os: multi-user?: sandbox: version: channels(m): nixpkgs:
I just noticed that I do not even get the GUI feature when building octave from nixpkgs (neither nor has a GUI).
Pinging: touched the package recently, is the maintainer of the package.
I’ll try to have a look when I have some time. I’ll let you know what I can achieve.
Here is what the configure script says:
yes, I got that and I fixed it. See for my attempt to build with Qt5 (which succeeds, but starting octave with gui fails - see PR).
Code change:
--replace /etc/openzwave $out/etc/openzwave ''; <del> fixupPhase = '' substituteInPlace $out/lib/pkgconfig/libopenzwave.pc  --replace prefix= prefix=$out  --replace dir=    dir=$out substituteInPlace $out/bin/ozw_config  --replace pcfile=${pkg-config} pcfile=$out ''; </del> meta = with lib; { description = "C++ library to control Z-Wave Networks via a USB Z-Wave Controller"; homepage = "http://www.openzwave.net/";

Related discussion:
text: Hi, i need to use open-zwave as a dependency for a build, but the version built in the Nix package is a specific fork for supporting home-assistant, which does not work for my package build due to linking errors. I will happily contribute a new package, but I'm not sure how to proceed, with regards to how it would fit in with this package, or if indeed the best way would be to modify this package to use the upstream repo. Pinging people who have maintained the package, apologies for the noise!
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
We should replace the package with an official version and make use the fork.
Code change:
pytestCheckHook ]; <ins> disabledTests = lib.optionals stdenv.isDarwin [ "test_run_local_server" ]; </ins> meta = with lib; { description = "Google Authentication Library: oauthlib integration"; homepage = "https://github.com/GoogleCloudPlatform/google-auth-library-python-oauthlib";

Related discussion:
text: Describe the bug Tensorflow binary builds don't work on mac os. (neither do the source build, but that's a separate issue) To Reproduce $ nix-build '<nixpkgs' --show-trace -A python37Packages.tensorflow-bin_2 this derivation will be built: /nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow- building '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-'... Sourcing python-recompile-bytecode- Sourcing python-remove-tests-dir-hook Sourcing python-catch-conflicts- Sourcing python-remove-bin-bytecode- Sourcing wheel setup hook Using wheelUnpackPhase Sourcing pip-install-hook Using pipInstallPhase Sourcing python-imports-check- Using pythonImportsCheckPhase Sourcing python-namespaces-hook unpacking sources Executing wheelUnpackPhase Finished executing wheelUnpackPhase patching sources configuring /private/tmp/nix-build-python3.7-tensorflow- /private/tmp/nix-build-python3.7-tensorflow- Unpacking to: unpacked/tensorflow-2.1.0...OK substitute(): ERROR: file '--replace' does not exist error: --- Error
--------------------------------------------------------------------------- nix-build builder for '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-' failed with exit code 1 host os: multi-user?: sandbox: version: channels(noah): nixpkgs: yaml attribute: module:
Code change:
pytestCheckHook ]; <ins> disabledTests = lib.optionals stdenv.isDarwin [ "test_run_local_server" ]; </ins> meta = with lib; { description = "Google Authentication Library: oauthlib integration"; homepage = "https://github.com/GoogleCloudPlatform/google-auth-library-python-oauthlib";

Related discussion:
text: Describe the bug tensorflow-bin_2 wants gast-3.2.0 due to but gast has been updated to 3.3.0 so tensorflow refuses to install: To Reproduce Notify maintainers Metadata Maintainer information:
There are also other dependencies that fail the version checks: scipy==1.4.1 and tensorflow-estimator<2.2.0,=2.1.0rc0.
This compiles i'll test it, any feedback appreciated
Got some issues
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Related .
It looks like fixes this.
Code change:
bgnet = callPackage ../data/documentation/bgnet { }; <del> bibata-cursors = callPackage ../data/icons/bibata-cursors { attrs = python3Packages.attrs; }; </del> bibata-extra-cursors = callPackage ../data/icons/bibata-cursors/extra.nix { }; bibata-cursors-translucent = callPackage ../data/icons/bibata-cursors/translucent.nix { };

Related discussion:
text: Package name: bibata-cursors Latest released version: 2.0.4 <!-- Search your package here: --- Current version on the unstable channel: 2.0.3 Current version on the stable/release channel: 2.0.3 <!-- 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.