jiebi/CodeConvo huggingface dataset:
Code change:
<ins> { lib, buildPythonPackage, fetchPypi, pythonOlder }: buildPythonPackage rec { pname = "pathvalidate"; version = "2.4.1"; disabled = pythonOlder "3.5"; src = fetchPypi { inherit pname version; sha256 = "sha256-PJvZTH7CPpz7IR/741audfl51sCZosdF7pSQ9STzJGg="; }; # Requires `pytest-md-report`, causing infinite recursion. doCheck = false; pythonImportsCheck = [ "pathvalidate" ]; meta = with lib; { description = "A Python library to sanitize/validate a string such as filenames/file-paths/etc"; homepage = "https://github.com/thombashi/pathvalidate"; license = licenses.mit; maintainers = with maintainers; [ oxalica ]; }; } </ins>

Related discussion:
text: Describe the bug failed to build on master. To Reproduce Steps to reproduce the behavior: nixpkgs master Expected behavior It builds. 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 Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(oxa): nixpkgs: Maintainer information:
Code change:
burp = callPackage ../tools/backup/burp { }; <del> buku = callPackage ../applications/misc/buku { }; </del> <ins> buku = callPackage ../applications/misc/buku { python3 = python36; # due to #52766 }; </ins> byzanz = callPackage ../applications/video/byzanz {};

Related discussion:
text: tests pass, while tests fail with: Official Hydra sees the same thing: with their Travis setup. (That is a build of a recent commit, but I still see the same failures after pointing at a checkout of ) Does anyone have any ideas? With nixpkgs master,
See scrapinghub/dateparser, scrapinghub/dateparser and scrapinghub/dateparser.
As long as this problem remains, the best thing to do is using for affected application. Switching to should be done in commits that don't change anything else and that reference this issue in their commit message so that they can easily be reverted. Simply skipping the tests does not make much sense since these are real incompatibilities.
Code change:
../libcxx/test/std/utilities/utility/mem.res/mem.res.pool/mem.res.pool.mem/unsync_allocate_overaligned_request.pass.cpp ../libcxx/test/std/utilities/utility/mem.res/mem.res.pool/mem.res.pool.mem/unsync_allocate_reuse_blocks.pass.cpp ../libcxx/test/std/utilities/utility/mem.res/mem.res.pool/mem.res.pool.mem/unsync_allocate.pass.cpp <ins> ../libcxx/test/std/language.support/support.dynamic/hardware_inference_size.compile.pass.cpp ../libcxx/test/std/language.support/support.dynamic/new.delete/new.delete.array/sized_delete_array14.pass.cpp ../libcxx/test/std/language.support/support.dynamic/new.delete/new.delete.single/sized_delete14.pass.cpp ../libcxx/test/libcxx/selftest/sh.cpp/empty.sh.cpp </ins>

Related discussion:
text: Steps to reproduce the behavior: distutils module was removed in python 3.12 <!-- 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]:
Code change:
++ lib.optional (enableStatic && enableShared) "static"; buildInputs = lib.optional pythonSupport python <ins> ++ lib.optional (pythonSupport && python?isPy2 && python.isPy2) gettext </ins> ++ lib.optional (pythonSupport && python?isPy3 && python.isPy3) ncurses # Libxml2 has an optional dependency on liblzma.  However, on impure # platforms, it may end up using that from /usr/lib, and thus lack a

Related discussion:
text: Unable to build libxml2 Repro: nix-env -i libxml2 make[4]: Entering directory '/private/var/folders/7g/1ptqqd597r76dqzk7hjy0bgc0000gn/T/nix-build-libxml2-' CC CC libxml2- CC libxml.c:1649:43: warning: passing 'unsigned char ' to parameter of type 'const char ' converts between pointers to integer types with different sign [-Wpointer-sign] message = libxmlcharPtrConstWrap(ptr); ^~~ ./libxmlwrap.h:240:48: note: passing argument to parameter 'str' here PyObject libxmlcharPtrConstWrap(const char str); ^ 1 warning generated.
Code change:
++ lib.optional (enableStatic && enableShared) "static"; buildInputs = lib.optional pythonSupport python <ins> ++ lib.optional (pythonSupport && python?isPy2 && python.isPy2) gettext </ins> ++ lib.optional (pythonSupport && python?isPy3 && python.isPy3) ncurses # Libxml2 has an optional dependency on liblzma.  However, on impure # platforms, it may end up using that from /usr/lib, and thus lack a

Related discussion:
text: CCLD ld: library not found for -lintl clang-7: error: linker command failed with exit code 1 (use -v to see invocation) make[4]: [Makefile:600: ] Error 1 make[4]: Leaving directory '/private/var/folders/7g/1ptqqd597r76dqzk7hjy0bgc0000gn/T/nix-build-libxml2-' make[3]: [Makefile:694: all-recursive] Error 1 make[3]: Leaving directory '/private/var/folders/7g/1ptqqd597r76dqzk7hjy0bgc0000gn/T/nix-build-libxml2-' make[2]: [Makefile:528: all] Error 2 make[2]: Leaving directory '/private/var/folders/7g/1ptqqd597r76dqzk7hjy0bgc0000gn/T/nix-build-libxml2-' make[1]: [Makefile:1479: all-recursive] Error 1 make[1]: Leaving directory '/private/var/folders/7g/1ptqqd597r76dqzk7hjy0bgc0000gn/T/nix-build-libxml2-' make: [Makefile:893: all] Error 2 builder for '/nix/store/xcqdl8cfjjbjvh7g9ka0ip3r4awy80a8-libxml2-' failed with exit code 2 error: build of '/nix/store/xcqdl8cfjjbjvh7g9ka0ip3r4awy80a8-libxml2-' failed Metadata* system: host os: multi-user?: sandbox: version: channels(swarnpriya): nixpkgs:
Disclaimer: I barely know what I'm doing. I tried adding as a build input to libxml2. That got this error:
I've been getting this as well, since . Any clue? I think this sort of thing has happened before, but I don't recall the details.
I thought somebody else already fixed this after some discussion no irc. My proposal was essentially the patch above but guarded for python2 only.
Code change:
<ins> { stdenv, fetchurl, ncurses }: stdenv.mkDerivation { name = "watch-0.2.0"; src = fetchurl { url = http://procps.sourceforge.net/procps-3.2.8.tar.gz; sha256 = "0d8mki0q4yamnkk4533kx8mc0jd879573srxhg6r2fs3lkc6iv8i"; }; buildInputs = [ ncurses ]; makeFlags = "watch usrbin_execdir=$(out)/bin" + (if stdenv.isDarwin then " PKG_LDFLAGS=" else ""); enableParallelBuilding = true; crossAttrs = { CC = stdenv.cross.config + "-gcc"; }; installPhase = "mkdir $out; mkdir -p $out/bin; cp -p watch $out/bin"; meta = { homepage = http://sourceforge.net/projects/procps/; description = "Utility for watch the output of a given command at intervals"; platforms = stdenv.lib.platforms.unix; }; } </ins>

Related discussion:
text: Which version does it attempt to build? See for explanation.
9
Hmm, are you sure procps(-ng) can work on darwin? I found just
The only reason I wanted it was for the utility, which does work on Darwin. Homebrew has a separate installation target for , so maybe we can do that too.
I see, I noticed that. I'll leave it open then.
Since there is now a specific watch expression, this is no longer a bug.
Code change:
<del> { lib, stdenv, fetchurl, autoreconfHook, pkg-config, fftw }: </del> <ins> { lib , stdenv , fetchurl , autoreconfHook , pkg-config , fftw , withFftw3 ? true }: </ins> stdenv.mkDerivation rec { pname = "speexdsp";

Related discussion:
text: Easyeffects crashes when Echo Canceller is used (at least when applied on input). I've been told that it works fine on arch linux. Though it might be my hardware that somehow makes it crash. Steps to reproduce the behavior: Echo Canceller module to the Input Easy Effects to one of recording apps It doesn't crash It doesn't write anything useful in the logs, just exits with code 137. Please run and paste the result.
I can reproduce it but it is not a regular crash – there is not core dump. It appears to be killed. Weirdly when I run it with: The termination is not caught.
For me it reproduced with gdb: Maybe it's terminated when child process is crashed?
hmm, it seems to be something wrong with speex when configured to use the fftw library... not sure what, but this doesn't crash:
The same also happens in Speech Processor effect now:
Unfortunately this didn't seem to do the trick for me, it still crashes with the Echo Canceller.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I have the same problem. The thing is, used to work OK on my system. Then I tried the module, after which this issue appeared. However, now it's persisting. I undid the change, even tried booting into old generation, but is still getting killed with the echo canceller on. For reference, this is what I used to try to enable the echo cancel module (not sure if it ever worked):
Code change:
}; }; <ins> imperative = { ... }: { imports = [ ../modules/profiles/minimal.nix ]; # add a virtual wlan interface boot.kernelModules = [ "mac80211_hwsim" ]; # wireless client networking.wireless = { enable = lib.mkOverride 0 true; userControlled.enable = true; allowAuxiliaryImperativeNetworks = true; interfaces = [ "wlan1" ]; }; }; </ins> # Test connecting to the SAE-only hotspot using SAE machineSae = machineWithHostapd { networking.wireless = {

Related discussion:
text: After installing a fresh system with the following configuration: the file is not created, hence wpasupplicant fails to start with the following error: nixpkgs
I don't know the logic of , but I think you're supposed to provide the file yourself. I guess it could be ed if wpa_supplicant fails without one.
You can do
That probably wouldn't work due to permissions. EDIT: wpa_supplicant is still running as root, so it should work.
Fixed in
Code change:
diff --git a/src/dist/component/package.rs b/src/dist/component/package.rs <del> index 4b432785..fa45e87e 100644 </del> <ins> index 3beddf54..0f859b8d 100644 </ins> --- a/src/dist/component/package.rs +++ b/src/dist/component/package.rs <del> @@ -109,10 +109,11 @@ impl Package for DirectoryPackage { match &*part.0 { "file" => { if self.copy { -                        builder.copy_file(path.clone(), &src_path)? +                        builder.copy_file(path.clone(), &src_path)?; </del> <ins> @@ -113,6 +113,7 @@ impl Package for DirectoryPackage { </ins> } else { <del> -                        builder.move_file(path.clone(), &src_path)? +                        builder.move_file(path.clone(), &src_path)?; </del> <ins> builder.move_file(path.clone(), &src_path)? </ins> } +                    nix_patchelf_if_needed(&target.prefix().path().join(path.clone()), &src_path) } "dir" => { if self.copy { <del> @@ -135,6 +136,22 @@ impl Package for DirectoryPackage { </del> <ins> @@ -135,6 +136,29 @@ impl Package for DirectoryPackage { </ins> } } +fn nix_patchelf_if_needed(dest_path: &Path, src_path: &Path) { <del> +    let is_bin = if let Some(p) = src_path.parent() { +        p.ends_with("bin") </del> <ins> +    let (is_bin, is_lib) = if let Some(p) = src_path.parent() { +        (p.ends_with("bin"), p.ends_with("lib")) </ins> +    } else { <del> +        false </del> <ins> +        (false, false) </ins> +    }; + +    if is_bin {

Related discussion:
text: Describe the bug As of rust nightly 2020-06-22, Rust nightly cannot find This issue is not present in Rust nightly 2020-06-21. To Reproduce Steps to reproduce the behavior: Expected behavior rustc works Additional context This also happens with rust nightly from Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(jade): nixpkgs: Maintainer information:
We are currently using in internally to set the elf interpreter. Looks like we need to extend this to also extend the RPATH to add zlib. If someone makes a PR, I will review it! Not sure when I would get to implement that myself.
Here is where we add :
I'm working on a patch for this. This is definitely the issue, just need to find the right way to extend the RPATH. I have something replacing it with a path containing zlib, but that overwrites the existing , which breaks it. I would like to verify what is setting there but hardcoding it should provide an early fix
Extending the RPATH seems not to have worked
I'm investigating patching the files in lib This issue may have been introduced by rust-lang/rust so it's likely the new zlib dependency shows up in the LLVM libraries
Code change:
chmod +x $out/bin/igv chmod +x $out/bin/igvtools ''; <ins> nativeBuildInputs = [ wrapGAppsHook ]; </ins> meta = with lib; { homepage = "https://www.broadinstitute.org/igv/";

Related discussion:
text: The IGV package freezes and crashed when a file dialog should open (open file, save as, etc.). Steps to reproduce the behavior: igv: igv "File" -"Load from File.." application crashes The file dialog should open and allow me to open a file. If I open igv through the terminal, then this error is shown: This error is the same as previously reported issues for other application, e.g. I'll shortly open a PR with the same fix. I'll rather do that in the PR with the fix. Please run and paste the result. NA
Code change:
<ins> { lib, buildPythonPackage, fetchPypi, pefile, pillow}: buildPythonPackage rec { pname = "icoextract"; version = "0.1.4"; src = fetchPypi { inherit pname version; extension = "tar.gz"; sha256 = "sha256-x0GEV0PUbkAzoUJgAqup9bHd7iYttGyzIZNdo8KsFyo="; }; propagatedBuildInputs = [ pefile pillow ]; # tests expect mingw and multiarch doCheck = false; pythonImportsCheck = [ "icoextract" ]; meta = with lib; { description = "Extract icons from Windows PE files"; homepage = "https://github.com/jlu5/icoextract"; license = licenses.mit; maintainers = with maintainers; [ bryanasdev000 ]; }; } </ins>

Related discussion:
text: Vulkan/dxvk doesnt work on bottles. Vulkan is working correctly on my laptop as vkcube, vulkaninfo and the game im trying to run on bottles (that i ran thru wineWowPackages.staging + dxvk install from the official archive file) run perfectly. Steps to reproduce the behavior: bottles a bottle for gaming a game. the "directx error" pop up. Also, the dxvk log files say that the "VKKHRsurface" extension failed to load. DXVK/Vulkan should work on bottles. ! Please run and paste the result.
Having the exact same Issue on 22.11pre393800. (Raccoon)
If fails then there is a driver issue. Vulkan wont be able to draw anything to screen without it. When it occurs in proton issues it's usually a missing 32bit Vulkan library. Tho there can ofc probably be other causes
update: using the system wine doesn't fix dxvk either. only running thru the command line does. As i said, running it thru wine on the terminal does work, so something in the bottles thing is not working right.
I found the cause: these hardcoded paths right there: With this extra lines in , Vulkan will work on Bottles: I'm not sure if this is the best way to solve it, though. Tested only on a 64-bit bottle (I don't know if 32-bit bottles need to also link ). .
!!! nice find!
Code change:
<ins> { lib, buildPythonPackage, fetchPypi, pefile, pillow}: buildPythonPackage rec { pname = "icoextract"; version = "0.1.4"; src = fetchPypi { inherit pname version; extension = "tar.gz"; sha256 = "sha256-x0GEV0PUbkAzoUJgAqup9bHd7iYttGyzIZNdo8KsFyo="; }; propagatedBuildInputs = [ pefile pillow ]; # tests expect mingw and multiarch doCheck = false; pythonImportsCheck = [ "icoextract" ]; meta = with lib; { description = "Extract icons from Windows PE files"; homepage = "https://github.com/jlu5/icoextract"; license = licenses.mit; maintainers = with maintainers; [ bryanasdev000 ]; }; } </ins>

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: bottles <!-- 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.5.28-trento-3 desired version: 2022.7.14-brescia-1 <!-- 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.
While automatic update using was removed by in you need to wait while we will "get auto updates from r-rynatm"
That not true. I removed the over complicated updater in which wasn't necessary at all. Since r-ryantm also uses nix-update there was also no need to replace it. That's wrong. You can always create an update PR yourself by running ` or by manually update the package and create a PR with that. r-ryantm goes through all packages so it can sometimes take a few days until the update PR is created. Also nix-update is very lightweight with minimal dependencies, so there is not really a reason to not use it. It also does not require any kind of token or authentication.
Bottles the version released after the one currently present in nixpkgs, was released on June 13. Over one month has passed, so something about the auto-updater isn't working.
The latest r-ryantm log is here . Not sure why that is not working like it should.
I guess a update script is needed for this case :disappointed: Since the package is using , it HAS a fallback update script , so nixpkgs-update is no longer trying to figure out the latest version itself but just run the script.
Code change:
<ins> { lib, buildPythonPackage, fetchPypi, pefile, pillow}: buildPythonPackage rec { pname = "icoextract"; version = "0.1.4"; src = fetchPypi { inherit pname version; extension = "tar.gz"; sha256 = "sha256-x0GEV0PUbkAzoUJgAqup9bHd7iYttGyzIZNdo8KsFyo="; }; propagatedBuildInputs = [ pefile pillow ]; # tests expect mingw and multiarch doCheck = false; pythonImportsCheck = [ "icoextract" ]; meta = with lib; { description = "Extract icons from Windows PE files"; homepage = "https://github.com/jlu5/icoextract"; license = licenses.mit; maintainers = with maintainers; [ bryanasdev000 ]; }; } </ins>

Related discussion:
text: However seems like cannot handle the version , so it will fail at You may just try Repology gets software latest version from various Linux distributions that ships this app, so since AUR and OpenMandriva have 2022.6.14 (no suffix) the latest version is 2022.6.14. Looks like there is also an related report in Note that nixpkgs-update does not really tries to bump package in this way because it has an fallback update script.
Code change:
buildPythonPackage rec { pname = "Shapely"; <del> version = "1.8.2"; </del> <ins> version = "1.8.4"; </ins> disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; <del> sha256 = "sha256-Vyr51QBv1eMhPjfuVIkSsDQfsmck1tyKTjlQwQGX67Y="; </del> <ins> sha256 = "sha256-oZXlHKr6IYKR8suqP+9p/TNTyT7EtlsqRyLEz0DDGYw="; </ins> }; nativeBuildInputs = [

Related discussion:
text: Add any other context about the problem here. Please run and paste the result. repro'd on commit id
backtrace: <details<summaryBacktrace from lldb</summary</details
shapely 1.8.4 with the fix is now in pypi, I saw you wanted to upgrade it, did you get around to do it?
thanks for the reminder, committed it
Code change:
"ftp://ftp.freedesktop.org/pub/mesa/${version}/mesa-${version}.tar.xz" "ftp://ftp.freedesktop.org/pub/mesa/older-versions/${branch}.x/${version}/mesa-${version}.tar.xz" ]; <del> sha256 = "1fqj2xhhd1ary0pfg31jq6fqcnd6qgyrw1445nmz554k8n2ck7rp"; </del> <ins> sha256 = "0awiyvicvcn3b18x0vx5ik3ly0k3k51ivz2ljj8pnx6ms95nyp2n"; </ins> }; prePatch = "patchShebangs .";

Related discussion:
text: Describe the bug VAAPI records repeated frames (see upstream bug report). upstream fix: To Reproduce Steps to reproduce the behavior: ... open OBS ... try recording using VAAPI (possible AMD hardware required?) ... watch replay Expected behavior full FPS. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
As for 21.0, the fix contained in upstream release = 21.0.2 so e.g. PR
Sadly a look at that thread, it's blocked because something broke, and they're not pushing it to 21.05, so this bug is going to exist until someone figures this out the regression, this patch is only one line of code, maybe it can be supplied as a patch until they get 21.0.3 working? Is there a way to build a patched mesa without rebuilding my entire desktop stack? It's currently stupidly slow on my computer when doing a packageOverride.
This will not be the only bug people will have to deal with on 21.05 unless we backport a more recent mesa (=21.1). Alternative we could also start to includes as well. Without it, this will lead to crashes in wine (incl. steam proton) when on some hardware ( for reference). While one can set as a workaround, it is hardly ideal and difficult to diagnose from within steam alone. Would it be possible to backport the mesa update currently in staging-next () once it is merged?
I don't know... this is hard. Maybe after a version has been a couple weeks in , we might be sufficiently confident that it won't make things worse overall.
I'm okay with backporting it, but probably as its own job set, just to get a better idea of regressions.
I'm not afraid of build-time regressions in this case. Those would be easy (to find). And mesa isn't such a big rebuild now anyway.
If it's been on unstable for a while, I guess I'm okay with it as well
I guess we can close this now, I haven't noticed any problems recently.
Code change:
--replace "include (''${CMAKE_CURRENT_SOURCE_DIR}/googletest.cmake)" "" --replace "include(GoogleTest)" "find_package(GTest REQUIRED)" <del> cat << EOF > python/triton/common/build.py </del> <ins> cat << EOF >> python/triton/common/build.py </ins> def libcuda_dirs(): return [ "${addDriverRunpath.driverLink}/lib" ] EOF

Related discussion:
text: Steps to reproduce the behavior: Commit seems likely to have broken the build for bitsandbytes. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I suspect the above output is related to that commit modifies or creates the module referenced above. I'm rebuilding setting the to and to to see if having dummy definitions solves the problem. Unfortunately it's slow going as it requires a full pytorch rebuild to see if it repaired bitsandbytes.
the trivial fix proposed above appears to resolve the build. Not sure if this would have ramifications elsewhere in the tree. Happy to PR the change if others want to help kick the tires
Oh!!! was mean to be a not ... how on earth did this even pass the tests (i.e. I only meant to abuse python's imperative-ness to override and keep all other symbols intact...)
a PR would be very welcome
looks like your original idea should also work, and be less broken in mysterious ways, I can do a quick PR after I make sure it works on my end.
Code change:
# does not contain any tests doCheck = false; <ins> enableParallelBuilding = true; </ins> pythonImportsCheck = [ "grpc" ]; meta = with lib; {

Related discussion:
text: Building uses more () threads than it should (i.e. 2 if / ). Steps to reproduce the behavior: as the build will use way more than 2 cores. Build should honour properly. This was with . This does not in fact use just 1 thread. :smilingfacewith_tear:. ! Happens on master () and 22.11.
I don't have any time planned to fix this but if you figure it out please send a PR.