jiebi/CodeConvo huggingface dataset:
Code change:
<ins> diff --git a/build.gradle b/build.gradle index c206e2f..cdaddf7 100644 --- a/build.gradle +++ b/build.gradle @@ -16,7 +16,7 @@ version = '0.22.3' sourceCompatibility = '17' repositories { -    mavenCentral() +    maven { url '@deps@' } } diff --git a/settings.gradle b/settings.gradle index f813993..2c87f3c 100644 --- a/settings.gradle +++ b/settings.gradle @@ -1 +1,7 @@ +pluginManagement { +    repositories { +        maven { url '@deps@' } +    } +} + rootProject.name = 'Stirling-PDF' </ins>

Related discussion:
text: Project description <!-- Describe the project a little: --Tools to manipulate pdf files. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'll see what I can do, should be good practice working with Gradle apps
Thank you Tom, much appreciated, best of luck.
By the way, I have pretty much succeeded in packaging it, and it seemed to run fine. Just forgot about it a little. The only issue with the package currently is that jar files are created non-deterministically by default (timestamps are not set to a fixed time). After using the fixup hook made for this situation (unzip and rezip the jar file) springboot doesn't recognise its files anymore, which is really weird. So it stayed non-deterministic. So I have two options: A) use the non-deterministic package or B) use the prebuilt jar from GitHub. The latter one is much less complex to work with.
See if this helps you.. or this discussion from the top (concerning java apps)...
Thanks for the pointers, though the second thing linked is my own post :) I finally managed to figure out how to fix the jar timestamps, so I'll open a PR adding the package
Thank you for your help . Much appreciated.. sorry for the delay. had a rough week last and it spilled into this one. Looking forward to using stirling-pdf on nixos.
Code change:
<del> { lib , fetchFromGitHub , python3 }: python3.pkgs.buildPythonApplication rec { pname = "crackmapexec"; version = "5.4.0"; format = "pyproject"; src = fetchFromGitHub { owner = "Porchetta-Industries"; repo = "CrackMapExec"; rev = "refs/tags/v${version}"; hash = "sha256-V2n840QyLofTfQE4vtFYGfQwl65sklp+KfNS9RCLvI8="; }; nativeBuildInputs = with python3.pkgs; [ poetry-core ]; propagatedBuildInputs = with python3.pkgs; [ aioconsole aardwolf beautifulsoup4 dsinternals impacket lsassy masky msgpack neo4j paramiko pylnk3 pypsrp pywerview requests requests-ntlm termcolor terminaltables xmltodict ]; postPatch = '' substituteInPlace pyproject.toml  --replace '{ git = "https://github.com/mpgn/impacket.git", branch = "master" }' '"x"' ''; pythonRelaxDeps = true; # Project has no tests doCheck = false; pythonImportsCheck = [ "cme" ]; meta = with lib; { description = "Tool for pentesting networks"; homepage = "https://github.com/Porchetta-Industries/CrackMapExec"; changelog = "https://github.com/Porchetta-Industries/CrackMapExec/releases/tag/v${version}"; license = with licenses; [ bsd2 ]; maintainers = with maintainers; [ fab ]; mainProgram = "cme"; }; } </del>

Related discussion:
text: crackmapexec fails to run on the unstable branch. Full backtrace : Steps to reproduce the behavior: Should be marked as broken for python 3.12 and above due to not being maintained anymore, it should be recommended to use the maintained fork . If applicable, add screenshots to help explain your problem. I may PR a proper fix later if I find time to do so <!-- 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]:
I don't know if removal was the best choice for this tool but maybe has all the features that had so it's alright. It's just that I'm not aware if there are any bugs that are not in that are in but I understand why removal makes sense since later we'll move onto later version of Python such as 3.13 and further more
As is a fork, I guess that the feature set is comparable or even bigger in the meantime. is still available for 24.05 and could still be used after 24.11 with some magic.
I ran into this issue where didn't have it, it is just a minor issue so it's alright on my side, but not sure if there will be any more issues I'll ran into later :
Code change:
meta = with lib; { description = "Your everyday IRC student"; homepage = "https://sr.ht/~taiite/senpai/"; <ins> changelog = "https://git.sr.ht/~delthas/senpai/refs/v${version}"; </ins> license = licenses.isc; maintainers = with maintainers; [ malte-v ]; };

Related discussion:
text: Package name: senpai Latest released version: 0.3.0 <!-- Search your package here: --- Current version on the unstable channel: 0.2.0 Current version on the stable/release channel: 0.2.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 Note for maintainers: Please tag this issue in your PR. Has new maintainer There are issues where the pulled dependencies don’t work with the 1.16 specified version. + (as well as 19) created a new batch of errors I decided to give up on. I did ask about in on their SourceHut issue tracker: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
(fetchNuGet { pname = "System.Security.Permissions"; version = "6.0.0"; sha256 = "0jsl4xdrkqi11iwmisi1r2f2qn5pbvl79mzq877gndw6ans2zhzw"; }) (fetchNuGet { pname = "System.Security.Principal"; version = "4.3.0"; sha256 = "12cm2zws06z4lfc4dn31iqv7072zyi4m910d4r6wm8yx85arsfxf"; }) (fetchNuGet { pname = "System.Security.Principal.Windows"; version = "4.3.0"; sha256 = "00a0a7c40i3v4cb20s2cmh9csb5jv2l0frvnlzyfxh848xalpdwr"; }) <ins> (fetchNuGet { pname = "System.Security.Principal.Windows"; version = "5.0.0"; sha256 = "1mpk7xj76lxgz97a5yg93wi8lj0l8p157a5d50mmjy3gbz1904q8"; }) </ins> (fetchNuGet { pname = "System.Security.Principal.Windows"; version = "6.0.0-preview.5.21301.5"; sha256 = "1q3iikvjcfrm5p89p1j7qlw1szvryq680qypk023wgy9phmlwi57"; }) (fetchNuGet { pname = "System.Text.Encoding"; version = "4.0.11"; sha256 = "1dyqv0hijg265dwxg6l7aiv74102d6xjiwplh2ar1ly6xfaa4iiw"; }) (fetchNuGet { pname = "System.Text.Encoding"; version = "4.3.0"; sha256 = "1f04lkir4iladpp51sdgmis9dj4y8v08cka0mbmsy0frc9a4gjqr"; })

Related discussion:
text: is not included in the version of xivlauncher in nixpkgs, meaning that xivlauncher is currently broken. The update will need a backport to 22.05. <!-- 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: xivlauncher <!-- 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: xlcore 1.0.0.9 (upstream release 6.2.33, which I think is probably a more useful version number to use, since xlcore remains at 1.0.0.9 in the most recent release) desired version: 6.2.44 <!-- 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.
Code change:
src = fetchsvn { url = "http://winetricks.googlecode.com/svn/trunk"; inherit rev; <ins> sha256 = "01v13qw4sxmfm09g9amqycnzy743gdrhvv23rjr9255dzlrj1s8f"; </ins> }; buildInputs = [ perl which ];

Related discussion:
text: CMake seems to use ps command internally, but looks like CMake in nix on darwin can not find ps command, so it complains with message "sh: ps: command not found." (very many times) Although this does not seem to harm build, it is desirable if this can be solved quite easily by some simple patch.
I found a similar problem report in macports. Shall we include /bin/ps visible in cmake environment in darwin systems?
Is there no way to hard-code the path of into CMake?
isn't actually in .
The relevant code in cmake is I believe. The package on contains the Apple ps. I'll likely get it building as part of my revamp of the darwin stdenv, and if I'm feeling particularly charitable I might even hook it into cmake. In the mean time, I'd probably just leave this alone, since I don't think we're far off from having a sensible darwin stdenv.
We definitely can't use procps on Darwin since it doesn't have /proc. Also, these warnings are not always harmless: MySQL's startup scripts won't work unless it has ps in scope during the build process. Right now the workaround is this
This was fixed as part of the new darwin stdenv.
Code change:
<ins> { lib , stdenvNoCC , fetchFromGitHub }: stdenvNoCC.mkDerivation (finalAttrs: { pname = "cmrc"; version = "2.0.1"; src = fetchFromGitHub { owner = "vector-of-bool"; repo = "cmrc"; rev = finalAttrs.version; hash = "sha256-++16WAs2K9BKk8384yaSI/YD1CdtdyXVBIjGhqi4JIk="; }; installPhase = '' runHook preInstall install CMakeRC.cmake -DT $out/share/cmakerc/cmakerc-config.cmake runHook postInstall ''; meta = { description = "A Resource Compiler in a Single CMake Script"; homepage = "https://github.com/vector-of-bool/cmrc"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ guekka ]; platforms = lib.platforms.all; }; }) </ins>

Related discussion:
text: Project description vcpkg is a package manager for C++ and many large and very small libraries are packaged there. Many of my projects use it for CMake configuration and for its toolchain file that automatically download and build libraries. I want to setup dev environment with nix and this is one of the packages I'm looking for that I've been building manually (since the brew packaged vcpkg is not well configured for manifest files support) Metadata homepage URL: source URL: license: MIT platforms: unix, linux, darwin, windows
I'll try something now.
Reading the , it looks like a case for a module, not merely a package.
I'm not sure what's the difference between a package and a module... but if it allows me to download a prebuilt binary of vcpkg that I can simply install, that's fine for me. Know that this package manager is made (partly) in C++ and need compiling. The build script is the you see there.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Maybe I am over-engineering here. Reading the AUR script, vcpkg uses systemd scripts/services. Therefore I think it requires more integration with the operating system. Modules are, roughly speaking, designed to "patch" and configure NixOS (the operating system).
Would be nice to have!
Work is ongoing here:
Code change:
final Uri entryUri = globals.fs.path.toUri(font['asset'] as String); result.add(_Asset( -        baseDir: globals.fs.path.join(Cache.flutterRoot, 'bin', 'cache', 'artifacts', 'material_fonts'), <del> +        baseDir: globals.fs.path.join(homeDirPath, '.cache', 'flutter', 'artifacts', 'material_fonts'), </del> <ins> +        baseDir: globals.fs.path.join(globals.fsUtils.homeDirPath, '.cache', 'flutter', 'artifacts', 'material_fonts'), </ins> relativeUri: Uri(path: entryUri.pathSegments.last), entryUri: entryUri, ));

Related discussion:
text: When trying to install , the build fails with: To reproduce, use the following and run it with : I think this happens because of the symlink of the , which seems to be resolved while running the build and in that case the symlink target does not exist. /cc btw: could you please also add support for the latest beta / dev / stable releases?
Hey it's fixed in the latest commit. Can you try it ?
Works fine, thank you very much for the fast fix!
Code change:
stdenv.mkDerivation rec { pname = "tomb"; <del> version = "2.7"; </del> <ins> version = "2.9"; </ins> src = fetchFromGitHub { owner  = "dyne"; repo   = "Tomb"; rev    = "v${version}"; <del> sha256 = "1vzkpzci6cp1r1q2n34pcgcns78i726k8d89dd6pibyj0vfnkl57"; </del> <ins> sha256 = "0d6vmfcf4kd0p2bcljmdnyc2fmbwvar81cc472zx86r7yc3ih102"; </ins> }; buildInputs = [ sudo zsh pinentry ];

Related discussion:
text: , CVSSv3=9.8 (nixos-20.09) Scanned versions: nixos-20.09: . Cc
Code change:
buildPackages.libgphoto2; in '' <del> mkdir -p $out/lib/udev/rules.d </del> <ins> mkdir -p $out/lib/udev/{rules.d,hwdb.d} </ins> ${executablePrefix}/lib/libgphoto2/print-camera-list  <del> udev-rules version 175 group camera  >$out/lib/udev/rules.d/40-gphoto2.rules </del> <ins> udev-rules version 201 group camera  >$out/lib/udev/rules.d/40-libgphoto2.rules ${executablePrefix}/lib/libgphoto2/print-camera-list  hwdb version 201 group camera  >$out/lib/udev/hwdb.d/20-gphoto.hwdb </ins> ''; meta = {

Related discussion:
text: We currently use version and export it to The help page suggests there is version 201 and the file name should be : () The change will also likely need a hwdb file according to: This is apparently required to support cameras that use SCSI tunneling support: cc (maintainer) ( the udev file)
For reference Fedora
Code change:
qtwebsockets = callPackage ./modules/qtwebsockets.nix { }; qtwebview = callPackage ./modules/qtwebview.nix { }; <del> wrapQtAppsHook = makeSetupHook { deps = [ self.qtbase.dev self.qtwayland.dev makeWrapper ]; </del> <ins> wrapQtAppsHook = makeSetupHook { deps = [ makeWrapper ]; </ins> } ./hooks/wrap-qt-apps-hook.sh; };

Related discussion:
text: low priority qt6.qtdeclarative is a large package, so it should be excluded for non-GUI qt apps () currently, when i build a package with and empty buildInputs, it pulls qt6.qtwayland qt6.qtdeclarative qt6.qtshadertools the problem is wrapQtAppsHook and its deps and qtwayland pulls qtdeclarative the problem is fixed by removing from deps wrapQtAppsHook should use only the declared buildInputs disabling wrapQtAppsHook (dontWrapQtApps = true) is no option, as also CLI qt apps need the qt wrapper qtwayland is there, so that users dont need to add it to buildInputs assuming that all qt apps are GUI apps im in favor of making this consistent with cmake so that all GUI apps must add qtwayland to buildInputs CLI qt app: GUI qt app: since cc
I'm in favour of this change, but the proportion of qt cli app night be relatively small, and it's not immediately clear that qtwayland should be if the build log yields Qt6::Widgets is missing.
Actually we are abusing qtwayland as a shortcut to bringing in qtdeclarative, this should be fixed too.
we could patch the cmake message to "please add qtdeclarative to your propagatedBuildInputs" the alternative would be to add a flag, but thats more obscure than buildInputs
Adding the lines to nixpkgs manual is sufficient.
By the way, is not only needed to pull in , but it's required for all GUI apps so that they work seamlessly on X11 or Wayland.
Code change:
esneider/YUNOcommit.vim euclidianAce/BetterLua.vim euclio/vim-markdown-composer <ins> evanleck/vim-svelte </ins> f-person/git-blame.nvim f3fora/cmp-spell famiu/bufdelete.nvim

Related discussion:
text: Project description Various vim plugins iamcco/coc-tailwindcss coc-extensions/coc-svelte evanleck/vim-svelte
Code change:
<ins> { lib , stdenv , fetchFromGitHub , cacert , cmake , cmakerc , fmt , git , gzip , makeWrapper , meson , ninja , openssh , python3 , zip , zstd , extraRuntimeDeps ? [] }: stdenv.mkDerivation (finalAttrs: { pname = "vcpkg-tool"; version = "2023-10-18"; src = fetchFromGitHub { owner = "microsoft"; repo = "vcpkg-tool"; rev = finalAttrs.version; hash = "sha256-Hm+GSKov9A6tmN10BHOTVy8aWkLOJNBMOQJNm4HnWuI="; }; nativeBuildInputs = [ cmake cmakerc fmt ninja makeWrapper ]; patches = [ ./change-lock-location.patch ]; cmakeFlags = [ "-DVCPKG_DEPENDENCY_EXTERNAL_FMT=ON" "-DVCPKG_DEPENDENCY_CMAKERC=ON" ]; postFixup = let # These are the most common binaries used by vcpkg # Extra binaries can be added via overlay when needed runtimeDeps = [ cacert cmake git gzip meson ninja openssh python3 zip zstd ] ++ extraRuntimeDeps; in '' wrapProgram $out/bin/vcpkg --prefix PATH ${lib.makeBinPath runtimeDeps} ''; meta = { description = "Components of microsoft/vcpkg's binary"; homepage = "https://github.com/microsoft/vcpkg-tool"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ guekka gracicot ]; platforms = lib.platforms.all; }; }) </ins>

Related discussion:
text: Project description vcpkg is a package manager for C++ and many large and very small libraries are packaged there. Many of my projects use it for CMake configuration and for its toolchain file that automatically download and build libraries. I want to setup dev environment with nix and this is one of the packages I'm looking for that I've been building manually (since the brew packaged vcpkg is not well configured for manifest files support) Metadata homepage URL: source URL: license: MIT platforms: unix, linux, darwin, windows
I'll try something now.
Reading the , it looks like a case for a module, not merely a package.
I'm not sure what's the difference between a package and a module... but if it allows me to download a prebuilt binary of vcpkg that I can simply install, that's fine for me. Know that this package manager is made (partly) in C++ and need compiling. The build script is the you see there.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Maybe I am over-engineering here. Reading the AUR script, vcpkg uses systemd scripts/services. Therefore I think it requires more integration with the operating system. Modules are, roughly speaking, designed to "patch" and configure NixOS (the operating system).
Would be nice to have!
Work is ongoing here:
Code change:
}; in rustPlatform.buildRustPackage rec { pname = "tokenizers"; <del> version = "0.8.1.rc1"; </del> <ins> version = "0.8.1"; </ins> src = fetchFromGitHub { owner = "huggingface"; repo = pname; rev = "python-v${version}"; <del> sha256 = "1bzvfffnjjskx8zlq1qsqfd47570my2wnbq4ip8i1hkz10q900qv"; </del> <ins> sha256 = "0sxdwx05hr87j2z32rk4rgwn6a26w9r7m5fgj6ah1sgagiiyxbjw"; </ins> }; <del> cargoSha256 = "0s5z3g1njb7wlyb32ba6xas4zc62c3zhmp1mrvghmaxpvljp6k7b"; </del> <ins> # Update parking_lot to be compatible with recent Rust versions, that # replace asm! by llvm_asm!: # # https://github.com/Amanieu/parking_lot/pull/223 # # Remove once upstream updates this dependency. cargoPatches = [ ./update-parking-lot.diff ]; cargoSha256 = "0cdkxmj8z2wdspn6r62lqlpvd0sj1z0cmb1zpqaajxvr0b2kjlj8"; </ins> sourceRoot = "source/bindings/python";

Related discussion:
text: Describe the bug , which is depended on by , has been failing to build on both Linux and macOS since / , perhaps since was updated in . of a contemporary build attempt indicate that the immediate problem is that the current version of tokenizers depends on a vendored copy of v0.10.0 of the parkinglot crate, via its cargoDeps dependency. Further research suggests that the -issue reported in the logs was fixed in Amanieu/parkinglot which it looks like is included in v0.10.1 and successors. As a result, I think that someone just needs to refresh tokenizers' (possibly by way of simply updating the package) or, failing that, to try to get it to build with an older version of . (That said, I have yet to test these changes myself, so I don't know if they are truly enough or if additional modifications are required.) To Reproduce Expected behavior The build should succeed. Notify maintainers (also /cc (since this looks like an interaction with and since there is a commit linked to above updating in the scmdiff from the last successful build to the first failing build, per hydra.) Metadata $ nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(...): nixpkgs: Maintainer information:
Thanks for the bug report (still hoping for Hydra notifications some day)! The linked PR should fix this issue. I am also working on some other PRs to make transformers work on Linux/AArch64 and Darwin/x86_64.
Code change:
doCheck = true; <ins> preFixup = '' makeWrapperArgs+=(  "''${gappsWrapperArgs[@]}"  --prefix PATH : "${lib.makeBinPath [ iw ]}"  ) ''; </ins> postFixup = '' wrapPythonPrograms <del> wrapProgram $out/bin/networkd-dispatcher --prefix PATH : ${lib.makeBinPath [ iw ]} </del> ''; meta = with lib; {

Related discussion:
text: Steps to reproduce the behavior: to NixOS config Successfully start. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
sbt-with-scala-native = callPackage ../development/tools/build-managers/sbt/scala-native.nix { }; simpleBuildTool = sbt; <ins> sbt-extras = callPackage ../development/tools/build-managers/sbt-extras { }; </ins> shallot = callPackage ../tools/misc/shallot { }; shards = callPackage ../development/tools/build-managers/shards { };

Related discussion:
text: I'm told a lot of people favor Paul Phillips' SBT wrapper over vanilla SBT. We probably ought to have a package for it.
Minus the parts where it auto-downloads sbt for you, I expect
Mmm, I don't know. Isn't it kind of important to be able to auto-download the appropriate version of sbt for each project?
Maybe? Seems hard to keep it Nix-flavored though, given that it wants to retrieve unhashed versions from the outside. I guess we could either patch it to call out to nix to download scala and sbt, or we could leave it alone and users can decide whether they care about Nix-like behavior here.
Code change:
listening_ip=${range} '') cfg.internalIPs} <ins> ${lib.optionalString (firewall == "nftables") '' upnp_table_name=miniupnpd upnp_nat_table_name=miniupnpd ''} </ins> ${cfg.appendConfig} ''; <ins> firewall = if config.networking.nftables.enable then "nftables" else "iptables"; miniupnpd = pkgs.miniupnpd.override { inherit firewall; }; firewallScripts = lib.optionals (firewall == "iptables") ([ "iptables"] ++ lib.optional (config.networking.enableIPv6) "ip6tables"); </ins> in { options = {

Related discussion:
text: We already have in , but only with iptables support. It would be nice to have the nftables version available as well.
Being worked on in , I'm trying to test myself but couldn't make it to work yet.
I think the PR is ready now, testing welcome!
Maybe add an option for will be better?