jiebi/CodeConvo huggingface dataset:
Code change:
# suppress warnings from compilation of the vendored clang to avoid running into log limits on the Hydra NIX_CFLAGS_COMPILE = lib.optionals stdenv.cc.isGNU [ "-Wno-shadow" "-Wno-maybe-uninitialized" ]; <del> # Workaround the xrootd runpath bug #169677 by prefixing [DY]LD_LIBRARY_PATH with ${lib.makeLibraryPath xrootd}. # TODO: Remove the [DY]LDLIBRARY_PATH prefix for xrootd when #200830 get merged. </del> postInstall = '' for prog in rootbrowse rootcp rooteventselector rootls rootmkdir rootmv rootprint rootrm rootslimtree; do wrapProgram "$out/bin/$prog"  <del> --set PYTHONPATH "$out/lib"  --set ${lib.optionalString stdenv.isDarwin "DY"}LD_LIBRARY_PATH "$out/lib:${lib.makeLibraryPath [ xrootd ]}" </del> <ins> --set PYTHONPATH "$out/lib" </ins> done # Make ldd and sed available to the ROOT executable by prefixing PATH.

Related discussion:
text: XRootD failed to access the files following the URL, complaining that isn't found and the authentication handler couldn't be loaded. However, does present in the output directory. Steps to reproduce the behavior: Enter the top directory of Nixpkgs See Run See the detailed output A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Terminal output during execution: Short: Long: is packaged by myself, but I haven't found the solution. Suggestions and helps are more than welcom. Please run and paste the result.
This is probably because has the wrong . How to fix that though? No idea.
Code change:
<ins> GEM remote: https://rubygems.org/ specs: addressable (2.8.0) public_suffix (>= 2.0.2, < 5.0) bson (4.14.1) ipaddr (1.2.4) json (2.6.1) mongo (2.17.1) bson (>= 4.8.2, < 5.0.0) public_suffix (4.0.6) rchardet (1.8.0) PLATFORMS ruby DEPENDENCIES addressable ipaddr json mongo rchardet BUNDLED WITH 2.1.4 </ins>

Related discussion:
text: Project description A scanner informing the technologies and headers a website uses. Metadata homepage URL: source URL: license: GPL-2.0 platforms: Agnostic (Darwin, Linux, Windows) See also:
I was able to build it, check it here
Thanks!
Code change:
+ optionalString propagateDoc '' ln -s ${cc.man} $man ln -s ${cc.info} $info <del> '' + optionalString (cc.langD or false) '' </del> <ins> '' + optionalString (cc.langD or cc.langJava or false) '' </ins> echo "-B${zlib}${zlib.libdir or "/lib/"}" >> $out/nix-support/libc-cflags ''

Related discussion:
text: NixOS's wrappers for gcc also apply for gcj, which is a Java compiler. The wrappers add the flag to gcj's command line, however the Java language does not have a preprocessor, and means a different thing for gcj. This means that gcj cannot compile anything. Another issue is that gcj links to zlib by default, but does not pull zlib into the environment. This means that, even if the former issue is silenced with , compilation still wouldn't work.
A similar problem for gfortran:
I marked this as stale due to inactivity. &rarr;
Code change:
license = licenses.asl20; maintainers = with maintainers; [ offline vdemeester periklis teutat3s ]; mainProgram = "docker"; <ins> inherit knownVulnerabilities; </ins> }; });

Related discussion:
text: Today one of my containers wouldn't start after I updated the docker-compose file and it was due to the docker engine being too old to support a certain feature. Easy enough to fix in config but is there a specific reason the attribute points at rather than ? Last time the attr was touched was
The reason is basically this: Quoting a recent comment in that PR:
Code change:
{ imports = [ <del> (mkRenamedOptionModule [ "nix" "useChroot" ] [ "nix" "useSandbox" ]) (mkRenamedOptionModule [ "nix" "chrootDirs" ] [ "nix" "sandboxPaths" ]) (mkRenamedOptionModule [ "nix" "daemonIONiceLevel" ] [ "nix" "daemonIOSchedPriority" ]) </del> <ins> (mkRenamedOptionModuleWith { sinceRelease = 2003; from = [ "nix" "useChroot" ]; to = [ "nix" "useSandbox" ]; }) (mkRenamedOptionModuleWith { sinceRelease = 2003; from = [ "nix" "chrootDirs" ]; to = [ "nix" "sandboxPaths" ]; }) (mkRenamedOptionModuleWith { sinceRelease = 2205; from = [ "nix" "daemonIONiceLevel" ]; to = [ "nix" "daemonIOSchedPriority" ]; }) </ins> (mkRemovedOptionModule [ "nix" "daemonNiceLevel" ] "Consider nix.daemonCPUSchedPolicy instead.") <del> ] ++ mapAttrsToList (oldConf: newConf: mkRenamedOptionModule [ "nix" oldConf ] [ "nix" "settings" newConf ]) legacyConfMappings; </del> <ins> ] ++ mapAttrsToList (oldConf: newConf: mkRenamedOptionModuleWith { sinceRelease = 2205; from = [ "nix" oldConf ]; to = [ "nix" "settings" newConf ]; }) legacyConfMappings; </ins> ###### interface

Related discussion:
text: The current process for renames puts out-of-tree modules in a situation where users are confronted with warnings they can't solve, and neither can the maintainers. Steps to reproduce the behavior: one change, create the new option/package/..., create the alias with a deprecation warning that goes into effect immediately -of-tree modules, such as home-manager, nix-darwin, start emitting warnings reports warning -of-tree module maintainer can't do anything, because stable release does not have the new option All generated warnings can be resolved by the user. Suggested process: one change, create the new option/package/... and the alias but no deprecation warning 1-7 months pass. All current branches now support the new way. enable the warning on master (more on that) -of-tree modules, such as home-manager, nix-darwin, start emitting warnings warnings can now be fixed To facilitate the process, we can add an argument to functions like to indicate the first release that will support the change. We'll maintain two (hidden?) version numbers that we update during the NixOS release process. For example, at the time of writing, the only supported stable version is 21.11 and 22.05 has not been released yet. To enable warnings on , we only need to update . Interestingly, we'll be deprecating functions that deprecate without . Sounds meta, but it's not complicated. It just means that some old style deprecations will slip through the net for some more time. (also a big one, but no complaints yet)
This is also related to NixOS/rfcs, which was a previous attempt at establishing general such deprecation behaviors
Code change:
sed -i "s#@TPM2_TSS@#${tpm2-tss.out}#" src/tpm2_pytss/FAPI.py ''; <ins> # Hardening has to be disabled # due to pycparsing handling it poorly. # See https://github.com/NixOS/nixpkgs/issues/252023 # for more details. hardeningDisable = [ "fortify" ]; </ins> nativeBuildInputs = [ cffi pkgconfig # this is the Python module

Related discussion:
text: <details<summary<codenix log /nix/store/xglq4zgrfjp92jrjn1d740wgssrzbqpy-python3.10-tpm2-pytss-</code</summary</detailsSeems to be the same error as , but the current (as of ) has the supposed fix (). Maybe one of the other patches since then ( ) re-introduced the build failure? Please run and paste the result.
I can confirm this failure
I am also hitting this issue. Both of the above mentioned commits build for me.
Build failure was introduced with
From the commits from that merge, narrowed it down to
Followed merges back up to , though both parents have the failure there... :(
I have this issue too. This is my error message: This is the full log:
I have the problem, too
I don't have a patch for it yet, but adding -DFORTIFYSOURCE=0 to this list gets it to build.
Unless I'm mistaken, that was the fix applied by &mdash; first patch in the list here:
It only add on L207, not on L187
[deleted]
Yeah, the overlay I build isn't working for me either. Not sure where I was that made it work...
find out it and u will be the hero hhh
Ok, found the exact PR causing the issue:
The issue is that nixpkgs now forces the fortify setting, ignoring whats set in project's files. So old method of disabling fortify for just one invocation is not enough I've been trying to use and then setting fortify settings in the environment, but that is not working. With , the package builds, but with that set, it seems that trying to enable fortification in the environment has no effect. So not sure how to enable fortify for the built object files.
The overlay I'm using until there is a better fix is:
Sorry for the lag, I'm out in holidays with family without much internet. I posted a fix in but I'm not sure I'll be able to follow up on it.
Code change:
<del> diff --git c/gr-utils/modtool/core/newmod.py w/gr-utils/modtool/core/newmod.py index babebfcde..9a02f663e 100644 --- c/gr-utils/modtool/core/newmod.py </del> <ins> diff --git i/gr-utils/modtool/core/newmod.py w/gr-utils/modtool/core/newmod.py index 8b222473f..c82fcd538 100644 --- i/gr-utils/modtool/core/newmod.py </ins> +++ w/gr-utils/modtool/core/newmod.py <del> @@ -62,7 +62,9 @@ class ModToolNewModule(ModTool): </del> <ins> @@ -66,7 +66,9 @@ class ModToolNewModule(ModTool): </ins> self._setup_scm(mode='new') logger.info(f"Creating out-of-tree module in {self.dir}...") try:

Related discussion:
text: Package name: gnuradio Latest released version: 3.10.8.0 <!-- Search your package here: --- Current version on the unstable channel: 3.10.7.0 Current version on the stable/release channel:3.10.7.0 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Tnx. Update is proposed at
Code change:
, setuptoolsRustBuildHook }: <del> let cryptography-vectors = callPackage ./vectors.nix { }; in </del> buildPythonPackage rec { pname = "cryptography"; version = "41.0.7"; # Also update the hash in vectors.nix

Related discussion:
text: Steps to reproduce the behavior:  nixos-unstable Noticed when setting and rebuilding &lt;!-- 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]:
You won't get a reply if you leave that empty.
I'm having the same issue I didn't notice when it happened, but I also have sambaFull
Same error whit the package .
This seems related to
That turned out not to be the issue. The actual error: In colour so that one can actually make sense of C++ error messages: ! One potential problem here: This is because of having: Switching to : Builds Removing entirely (which swiches to ): Fails on new related errors (see below) Removing and : Fails because Ceph requires lua = 5.3 and nixpkgs's default is still 5.2: CMake saysCould NOT find Lua (missing: LUAINCLUDEDIR) (Required is at least version "5.3")` Build failure with : <details</detailsI noticed Arch . But we can just use to fix the build.
PR for the
Code change:
operator = const [ ]; }); <del> urls = map (drv: { url = head (drv.urls or [ drv.url ]); hash = drv.outputHash; type = drv.outputHashAlgo; name = drv.name; }) fetchurlDependencies; </del> <ins> urls = map (drv: { url = head (drv.urls or [ drv.url ]); hash = drv.outputHash; isPatch = (drv?postFetch && drv.postFetch != ""); type = drv.outputHashAlgo; name = drv.name; }) fetchurlDependencies; </ins> fetchurlDependencies = filter (drv: drv.outputHash or "" != "" && drv.outputHashMode or "flat" == "flat" <del> && drv.postFetch or "" == "" && (drv ? url || drv ? urls)) </del> <ins> && (drv ? url || drv ? urls)) </ins> dependencies; dependencies = map (x: x.value) (genericClosure {

Related discussion:
text: The script should report all sources used to build a package. It currently lacks support for patches? If we run find-tarballs on nethack, we should find the patch defined in nethack named we should get the url to download in the output, along with its name, hash and type.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I found why patches are skipped, they have "postFetch" attribute that has to be run to obtain the same file expected by nix. By applying this diff, patches are included in the result, but they won't have the expected checksum before applying postFetch on it. I don't know how to apply postFetch on the result right now.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Code change:
<ins> #! @shell@ # shellcheck shell=bash exec @prog@ --enable-deterministic-archives "$@" </ins>

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:
gitMinimal ]; <del> meta = { </del> <ins> meta = with lib; { </ins> description = "Linting for your git commit messages"; <del> homepage = "http://jorisroovers.github.io/gitlint"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ ethancedwards8 ]; </del> <ins> homepage = "https://jorisroovers.com/gitlint/"; license = licenses.mit; maintainers = with maintainers; [ ethancedwards8 fab ]; </ins> }; }

Related discussion:
text: Describe the bug Gitlint fails to build due to a dependency on click v7.1.2 To Reproduce Steps to reproduce the behavior: Expected behavior Successful build of gitlint Screenshots ! Additional context Looks like click got separated into two packages, one where it updated to 8.0.1 and is present in and one where it was kept back for . Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(david): nixpkgs: Maintainer information:
Yeah this is interesting. As far as I know, things shouldn't just break like this. I assume this is a regression, as it used to build, it seems a LOT of stuff has started breaking.
doesn't work with later releases. We have 8.0.1 and is pinning all releases (affects also , I guess). It would requires that is overriding the releases.
could you please give a try?
Looks to be good on my system. Runs as intended with
Code change:
ppl-address-book = throw "deprecated in 2019-05-02: abandoned by upstream."; processing3 = processing; # added 2019-08-16 procps-ng = procps; # added 2018-06-08 <ins> pygmentex = texlive.bin.pygmentex; # added 2019-12-15 </ins> pyo3-pack = maturin; pmenu = throw "pmenu has been removed from nixpkgs, as its maintainer is no longer interested in the package."; # added 2019-12-10 pulseaudioLight = pulseaudio; # added 2018-04-25

Related discussion:
text: I have installed the TeXLive package on my system, but its binary script fails to run because: its directory is not found in it does not have an explicitly dependency on it does not have an explicitly dependency on the module for Python 2 cannot be found. Please fix this issues so that the script can be run. (Maybe can take a look at this.)
cc
Well, the first two bullets would be fixed very simply by but I don't yet have framework to add external python dependencies to the scripts.
Nothing new here? A similar problem happens with :
cc Maybe while a good solution is not engineered, a package for without the TeX stuff can be to . It would contain the binary with support for the needed Python dependencies. What do you think?
There aren't any true binaries, are there? It's just python scripts IIRC. But still, what you propose is probably the easiest way to resolve this somehow.
It is just a Python script that depends on the module.
My attempt at it:
So pygmentex works as expected now?
It works! It can be tested by downloading the example document from the distribution on , unzipping the downloaded files, removing the Python script and the LaTeX style class, and than compiling : The result is , with many examples of code listings typeset by Pygments.
OK, then I think we can close this.
Sorry for necromancing this (should I have opened a new issue instead?), but it doesn't "just work" – or needs further documentation on how to use it: The created by building the pygmentex texlive package can not find the module. gives us such an environment, just try running the command from there -The package though provides a executable which works just fine and finds the needed pygments python module. So how to combine these both packages? In particular I ran into this when trying to use the texlive package, as that seems to directly invoke the executable during build. Issue appears on release-18.09
I encountered the same issue, the latex package seems to be working fine tough (and can be used as a replacement)
I have in both with (which provides the style file and a non-functional Python script, because of missing Python dependencies) and (which provides the script). This setup works for me.
I still do not know a way of allowing Python module dependencies for Python scripts installed through .
This is to be fixed in
Code change:
gocd-server = callPackage ../development/tools/continuous-integration/gocd-server { }; <ins> gotify-server = callPackage ../servers/gotify { }; </ins> gotty = callPackage ../servers/gotty { }; gputils = callPackage ../development/tools/misc/gputils { };

Related discussion:
text: Project description A simple server for sending and receiving messages in real-time per WebSocket. Includes a web UI, also has an Android client for receiving notifications and an optional CLI program (distributed separately) for sending notifications. Metadata homepage URL: source URL: license: MIT platforms: anything Go runs on
I started an attempt locally, however it failed due to some timeouts while fetching Go dependencies... will retry during this week :)
I think the main difficulty is the UI, which needs to be compiled with NPM. In essence, I think the build is three-staged: fetch UI dependencies, fetch Go dependencies, do the actual build.
You may want to take a look at .
Code change:
stdenv.mkDerivation rec { pname = "river"; <del> version = "unstable-2021-09-30"; </del> <ins> version = "unstable-2021-11-01"; </ins> src = fetchFromGitHub { owner = "ifreund"; repo = pname; <del> rev = "e6bb373240bc08668c8e6e14996a3f8765941158"; sha256 = "sha256-dYruRpsud2XYrVY2f4f2dkRRSh1oU9rn2GRwAkJqW3A="; </del> <ins> rev = "363fd3f6a466004eec157a40e51684e56992b857"; sha256 = "sha256-RzReUo1p2z4UQaO5n6PKQlEv0vTBGg+1Wq1UIYii0Mo="; </ins> fetchSubmodules = true; };

Related discussion:
text: The doesn't start 'cause probably the wlroots it's causing a compatibility issue. Everytime that i try start river, it doesn't open. I searched on official repository and i found this issue: The current river's version on nixpkgs repository use wlroots 0.13.0, however the available on repository it's 0.14.1. Maintainers:
I'm not maintainer for months so I don't really care.
I'll get to updating it in about ~2 hours.
Code change:
externalDeps' = lib.filter (dep: !lib.isDerivation dep) externalDeps; in toLuaModule ( lua.stdenv.mkDerivation ( <del> builtins.removeAttrs attrs ["disabled" "checkInputs" "externalDeps"] // { </del> <ins> builtins.removeAttrs attrs ["disabled" "checkInputs" "externalDeps" "extraVariables"] // { </ins> name = namePrefix + name;

Related discussion:
text: Describe the bug neovim fails to build with missing , similar to , on . To Reproduce Steps to reproduce the behavior: to from master () Expected behavior The package should successfully build. Metadata On master () Maintainer information:
via in
so you could do until a proper fix.
Reverting the luarocks bump doesn't work for me. That fix is also very surprising to me, since neovim broke (for me) after the latest nixos-unstable channel update.
Interesting. It worked fine for me. Running the above revert command and then (inside my local nixpkgs with it reverted) let me build neovim properly. I don't think it's particularly surprising if updating a channel that happens to include the luarocks bump causes it to break, unless I'm misunderstanding you.
I updated from a channel where the luarocks bump had already happened, and neovim worked on that channel. In fact, I reverted to the previous hydra evaluation to make my system evaluate again.
This was actually before and it was working without problems and then suddenly the problem appeared again. I can also report that I cam getting this in the same way described (updated latest nixos-unstable channel and then neovim stopped building again).
I confirm this fixed by on master (channels may take a while). For now I'll assume that charvp's failure to resolve the issue with that revert was some kind of mistake; we can re-open otherwise, perhaps separately if it's a different kind of error.
Does anyone know why updating the luarocks dependency is so brittle? Is it possible to at least add a test so we don't regress again in the future?
the tool exists (nixpkgs-review) but it takes CPU and disk space to run plus some reviewer time (and was not run in this case). Also for this specific case, the luarocks update broke in subtle ways the build so I wouldn't call it . It is called unstable for a reason. The good thing about nixpkgs is you can pin neovim to an older version while keeping your system on unstable.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Are we sure this is fixed on Darwin? still shows failing with logs of: Or is this a different issue?