jiebi/CodeConvo huggingface dataset:
Code change:
julia = julia-stable; julia_16-bin = callPackage ../development/compilers/julia/1.6-bin.nix { }; <del> julia_17-bin = callPackage ../development/compilers/julia/1.7-bin.nix { }; </del> <ins> julia_18-bin = callPackage ../development/compilers/julia/1.8-bin.nix { }; </ins> julia-lts-bin = julia_16-bin; <del> julia-stable-bin = julia_17-bin; </del> <ins> julia-stable-bin = julia_18-bin; </ins> julia-bin = julia-stable-bin; jwasm =  callPackage ../development/compilers/jwasm { };

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: <!-- 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: 1.7.3 desired version: <!-- 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.
I started preparing the update in . Cc:
Code change:
, which , xdg-user-dirs , zlib <ins> # Affects final license , withAngrylionRdpPlus ? false </ins> }: let

Related discussion:
text: There is a license violation in the package. The package contains the code for under the old MAME license which is non-commercial and incompatible with the GPL code in the rest of the program. I tried to notify upstream, but that didn't seem to go well...
Hello! It seems that upstream actually an option to disable in version of . , from my testing, gives me an error when I try to run it. You can find more info in this . So, i think merging the pull request linked to this issue is the best option right now.
Code change:
<ins> { stdenv , lib , fetchFromGitHub , cmake , libxml2 , libpeas , glib , gtk3 , gtksourceview4 , gspell , xapps , pkg-config , meson , ninja , wrapGAppsHook , intltool , itstool }: stdenv.mkDerivation rec { pname = "xed-editor"; version = "2.8.4"; src = fetchFromGitHub { owner = "linuxmint"; repo = "xed"; rev = version; sha256 = "1hqr4157kp110p01jygqnnzj86zxlfiq4b53j345vqpx0f80c340"; }; nativeBuildInputs = [ meson cmake pkg-config intltool itstool ninja wrapGAppsHook ]; buildInputs = [ libxml2 glib gtk3 gtksourceview4 libpeas gspell xapps ]; postInstall = '' glib-compile-schemas $out/share/glib-2.0/schemas ''; doInstallCheck = true; installCheckPhase = '' if [[ "$($out/bin/xed --version)" == "xed - Version ${version}" ]] ; then echo "${pname} smoke test passed" else echo "${pname} smoke test failed" return 1 fi ''; meta = with lib; { description = "Light weight text editor from Linux Mint"; homepage = "https://github.com/linuxmint/xed"; license = licenses.gpl2Only; platforms = platforms.linux; maintainers = with maintainers; [ tu-maurice ]; }; } </ins>

Related discussion:
text: Xed Text Editor from Linux Mint Text editor from the Linux Mint distribution xed text editor homepage URL: source URL: license: gpl2 platforms: linux
needs an update of a dependency to package newest version 2.8.4
Code change:
<del> { lib, stdenv, fetchFromGitHub, cmake, pkg-config, gettext, libXpm, libGL, fltk, hicolor-icon-theme, glib, gnome2, which }: </del> <ins> { lib, stdenv, fetchbzr, cmake, pkg-config, gettext, libXpm, libGL, fltk, hicolor-icon-theme, glib, gnome2, which }: </ins> <del> stdenv.mkDerivation { </del> <ins> stdenv.mkDerivation rec { </ins> pname = "jwm-settings-manager"; <del> version = "2018-10-19"; </del> <ins> version = "2019-01-27"; </ins> <del> src = fetchFromGitHub { owner = "Israel-D"; repo = "jwm-settings-manager"; rev = "cb32a70563cf1f3927339093481542b85ec3c8c8"; sha256 = "0d5bqf74p8zg8azns44g46q973blhmp715k8kcd73x88g7sfir8s"; </del> <ins> src = fetchbzr { url = "lp:${pname}"; rev = "292"; sha256 = "1yqc1ac2pbkc88z7p1qags1jygdlr5y1rhc5mx6gapcf54bk0lmi"; </ins> }; nativeBuildInputs = [

Related discussion:
text: The repo URL is missing for: To fix it, you can fork (I forked it for preservation but neither of us made changes: ) then change the GitHub username in the nix file to yours. I don't have NixOS or have any way to test this. I ran into your nix file while trying to find the maintainer: I asked whether the repo has moved because it is deleted from GitHub. I contacted him via 's contact form and I'm awaiting a response (I didn't try an e-mail address found here yet: ).
Recently I have read somewhere that the author was absent from some social media, and that for personal reasons he has removed his account on github, and that this software is still available on launchpad. Github was just a second home for it. But I am not finding this info anymore.
Ok, the author responded to me via e-mail that the launchpad URL is correct, but that he isn't maintaining it. He says he's more likely to rewrite it in Rust rather than update it. The nix file can be corrected to use launchpad, but in light of that information, using one of the GitHub forks or forking one of them yourself and turning on the "Issues" feature is probably the best route to a future for it, even to a minimal extent of getting bugfixes.
I am changing the upstream source to the launchpad repository, as it is the most correct. I am also watching the two forks on github, so that I will be notified of new actions on them.
Code change:
allow_anonymous = 1; allow_zero_length_clientid = 1; auto_id_prefix = 1; <ins> bind_interface = 1; </ins> cafile = 1; capath = 1; certfile = 1;

Related discussion:
text: lists a listener option called that can be used to listen for incoming network connections only on the specified interface. Unfortunately does not accept this option. Steps to reproduce the behavior: This should evaluate cleanly. Incidentally, that assertion message drops the component in the attribute path, it might be nice to fix that.
Code change:
<ins> { config, lib, pkgs, ... }: let cfg = config.programs.streamcontroller; in { options.programs.streamcontroller = { enable = lib.mkEnableOption "StreamController"; package = lib.mkPackageOption pkgs "streamcontroller" { default = [ "streamcontroller" ]; }; }; config = lib.mkIf cfg.enable { environment.systemPackages = [ cfg.package ]; services.udev.packages = [ cfg.package ]; }; meta.maintainers = with lib.maintainers; [ sifmelcara ]; } </ins>

Related discussion:
text: Project description As discussed in is now EOL and the dev's have moved their effort to . As per the in order for it to work specific need to be set up. We can probably do something similar to what we do for the expression: Metadata homepage URL: source URL: license: GPL3 platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
For people who subscribed to this issue: I opened to add streamcontroller
Code change:
xorg.libXi xorg.libXrandr xorg.libXrender <del> xorg.libxshmfence </del> xorg.libXtst xorg.libxkbfile <ins> xorg.libxshmfence </ins> ] + ":${stdenv.cc.cc.lib}/lib64"; buildInputs = [ <del> gtk3  # needed for GSETTINGS_SCHEMAS_PATH </del> <ins> gtk3 # needed for GSETTINGS_SCHEMAS_PATH </ins> ]; nativeBuildInputs = [ dpkg makeWrapper nodePackages.asar ];

Related discussion:
text: Describe the bug Starting slack doesn't show the window in 8 out of 10 runs To Reproduce Steps to reproduce the behavior: Expected behavior Slack window should open Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. 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(ymatsiuk): channels(root): nixpkgs: Maintainer information:
Code change:
environment.systemPackages = [ cfg.services.nextcloud.occ ]; }; <ins> nextcloudWithoutMagick = args@{ config, pkgs, lib, ... }: lib.mkMerge [ (nextcloud args) { services.nextcloud.disableImagemagick = true; } ]; </ins> }; <del> testScript = let </del> <ins> testScript = { nodes, ... }: let </ins> withRcloneEnv = pkgs.writeScript "with-rclone-env" '' #!${pkgs.runtimeShell} export RCLONE_CONFIG_NEXTCLOUD_TYPE=webdav

Related discussion:
text: There is about the use of imagemagick in NextCloud due to . Admins may want to disable it unless they are certain that users won't upload untrusted files (which can easily happen by accident if folder sync is active). NextCloud is only passing certain file types to imagemagick but it is doing so based on the file extension. Therefore, an attacker can pass any file type to imagemagick. I have tested this with a PNM image (not supported by NextCloud) that I have renamed to . doesn't get a preview image but does, i.e. NextCloud thinks it is HEIF and passes it to ImageMagick, which processes it as PNM. There are several ways to disable imagick: in the NextCloud config. This will not only disable imagick but also previews for PNG and JPEG (which do not use imagick). in the NextCloud config. This may need manual adjustment after a NextCloud update. the extension for PHP. This also disables it for NextCloud plugins. Option 1 and 2 can already be used by an admin if the drawbacks are acceptable. However, I think 3 is the best option in most cases. has options that disable the other PHP extensions that used to be by default. I think we should do the same for imagick. If imagick is disabled, NextCloud will automatically disable the preview generators that need it. It will also show a warning about that (which is subject to debate in the issue linked above) and there may be some implications for the themes app (which I don't use). Therefore, I think we should keep imagick enabled by default and leave the decision to the admin. We could also add a suitable policy for ImageMagick and thereby disable any file formats or features that are considered insecure. I don't think I could write such a policy and be sure that it is secure (or even "secure enough"). In addition, we will have to keep it up-to-date with newer versions and CVEs. That is why I recommend that we only add a simple off switch. The above information is based on NextCloud 20. I will wait until and NextCloud 21 have landed in nixos-unstable (and on my server) and then test again and create a PR if there is any interest in having this upstream.
Code change:
environment.systemPackages = [ cfg.services.nextcloud.occ ]; }; <ins> nextcloudWithoutMagick = args@{ config, pkgs, lib, ... }: lib.mkMerge [ (nextcloud args) { services.nextcloud.disableImagemagick = true; } ]; </ins> }; <del> testScript = let </del> <ins> testScript = { nodes, ... }: let </ins> withRcloneEnv = pkgs.writeScript "with-rclone-env" '' #!${pkgs.runtimeShell} export RCLONE_CONFIG_NEXTCLOUD_TYPE=webdav

Related discussion:
text: Ouch, decisions based purely on a file ext is a behavior that sounds pretty broken to me :/ Optiobally disabling imagemagick and adjusting the config accordingly sounds reasonable to me, so feel free to file a PR. You can ping me for a review or if you need assistance with modifying the module :)
It's ok for what they do with it. It won't do double duty as a mitigation but I guess that was never intended. Thanks. Any suggestions on a name for the new option? Simply ? Should I add any tests for that? The existing tests only test three different configurations so adding one just for imagick seems like overkill. It should be quite easy though. If we want to test that previews actually aren't generated... Well, that's a different story. We would have to automate the web interface, for that. I think the existing tests are only testing the service, CLI and WebDAV.
As imagemagick enabled will remain the default, I'd suggest . Yes, adding a fourth VM test just for imagemagick is indeed an overkill IMHO since those tend to be fairly expensive. I'd suggest to write a testcase in , other integrations such as are also tested there. Right that could be a non-trivial thing to solve. Maybe check if there's a REST API or a way to implement this with the CLI of . But I don't think it'd be worth spending too much time on this if there's no reasonable way to test :)
I think we still want to test the default option in so we will need a second configuration that disables imagick. We don't have to start that VM if we only want to check whether imagick is in its closure. As there isn't any test helper for that, we probably don't want to do that though ;-) see Unfortunately, qemu on ARM is too unreliable for the automatic tests because qemu crashes when started on one of the little cores (i.e. 4 out of 6 times). I have done some interactive testing of the above commit but not an automated run. I will have to find some system that is not ARM, not high-security, not already virtualized...
Qemu/KVM does work if a kernel build or stress-ng is hogging the big cores :) is ready for review.
Code change:
meshlab = libsForQt5.callPackage ../applications/graphics/meshlab { }; <ins> metadata-cleaner = callPackage ../applications/misc/metadata-cleaner { }; </ins> metersLv2 = callPackage ../applications/audio/meters_lv2 { }; mhwaveedit = callPackage ../applications/audio/mhwaveedit {

Related discussion:
text: Project description Metadata proposed package name: homepage source URL: license: platforms: probably portable to all platforms which Nix supports. requires python3, exiftool, gobject introspection
Code change:
wrapProgram $out/bin/apx --prefix PATH : ${lib.makeBinPath [ docker distrobox ]} <del> installManPage man/apx.1 man/es/apx.1 </del> <ins> installManPage man/de/man1/apx.1 man/es/man1/apx.1 man/fr/man1/apx.1 man/it/man1/apx.1 man/man1/apx.1 man/nl/man1/apx.1 man/pl/man1/apx.1 man/pt/man1/apx.1 man/pt_BR/man1/apx.1 man/ro/man1/apx.1 man/ru/man1/apx.1 man/sv/man1/apx.1 man/tr/man1/apx.1 </ins> ''; meta = with lib; { description = "The Vanilla OS package manager"; homepage = "https://github.com/Vanilla-OS/apx"; <del> license = licenses.gpl3; </del> <ins> changelog = "https://github.com/Vanilla-OS/apx/releases/tag/${version}"; license = licenses.gpl3Only; </ins> maintainers = with maintainers; [ dit7ya ]; }; }

Related discussion:
text: Package name: Apx Latest released version: 1.8.2 <!-- Search your package here: --- Current version on the unstable channel: 0-1 Current version on the stable/release channel: N/A <!-- 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.
Code change:
cp -r ../include $out/ ''; <ins> passthru.tests = { inherit obs-studio; # frequently breaks on CEF updates }; passthru.updateScript = ./update.sh; </ins> meta = with lib; { description = "Simple framework for embedding Chromium-based browsers in other applications"; homepage = "https://cef-builds.spotifycdn.com/index.html";

Related discussion:
text: I just filed a to update our version of CEF to fix a . The previous version was released on 2019-07-27— that's almost 2 years! For a piece of software that's functionally a web browser, we certainly shouldn't be using an out-of-date version: web browsers have a massive attack surface and it's very important to keep them updated at all times. I don't have the time to work on this right at the moment, but it shouldn't be too difficult. There's a containing metadata for every CEF release. All that should be necessary is to grab the latest stable version for the right platform. While we're at it, we could also consider building for i686 and AArch64. Tagging the maintainer
IDK how it works, but it sounds like a job for the bot ().
Code change:
<del> { stdenv , lib , fetchFromGitHub , cmake , ninja , pkg-config , libnice , openssl , plog , srtp , usrsctp </del> <ins> { stdenv, lib, fetchFromGitHub, cmake, ninja, pkg-config, libnice, openssl, plog, srtp, usrsctp, </ins> }: stdenv.mkDerivation rec {

Related discussion:
text: HTTP Toolkit is an open-source tool for debugging, testing and building with HTTP(S) on Windows, Linux & Mac. Metadata homepage URL: source URL: license: AGPL v3.0 platforms: linux, darwin
Sorry, wasn't able to get it working. The httptoolkit-server is the difficult part. I tried building from source, however one of the dependencies tries to npm install more stuff in prebuild, so it wasn't building properly. I tried packaging the prebuilt binary but it's trying to do some auto updating and also package node with itself. I could have patched this when building from source, however the prebuilt one is minified & obfuscated so I couldn't do that.
Have you a branch to continue the work ?
+1
I've started a small bounty of 20$ on this: It's not much but it would be great to have this tool on nix!
I made another attempt at packaging this and I'm pretty close to getting httptoolkit-server to compile from source. This should help with patching out stuff, since we can do it before it gets obfuscated.
if anyone needs to run this on nix the appimage provided by HttpToolkit works pretty well on nix with no extra dependencies. See and then Would still be great to have this as a nix package though.
Hey thanks for adding this! You can claim the gitpay bounty here: (I've tried to find your email to invite you but didn't have much luck) or email me at
Sent you an email,
Code change:
- Sega Saturn (experimental, x86_64 only) - Sony PlayStation ''; <del> homepage = "https://mednafen.github.io/"; license = licenses.gpl2; </del> <ins> license = licenses.gpl2Plus; </ins> maintainers = with maintainers; [ AndersonTorres ]; platforms = platforms.linux; };

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: mednafen <!-- 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: 1.26.1 (dated November 10, 2020) desired version: 1.29.0 (dated January 19, 2022) <!-- 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:
owner = "fsspec"; repo = pname; rev = version; <del> hash = "sha256-gIkK1VSg1h04+MQBoxFtXIdn80faJlgQ9ayqV5p0RMU="; </del> <ins> hash = "sha256-BnnKFrWz47izKc7nS8NR1Vze1x9kJdYBsQT2KEY9ghM="; </ins> }; propagatedBuildInputs = [

Related discussion:
text: Steps to reproduce the behavior: dvc with aws integration I am running nixos on the unstable branch. Please run and paste the result. Probably fsspec needs an update to 2022.8.2
Will be fixed with .
Oh sorry for the noise, did not search the PRs.
Code change:
with lib; <ins> let workDir = if cfg.workDir == null then runtimeDir else cfg.workDir; in </ins> { description = "GitHub Actions runner";

Related discussion:
text: Working with large repositories on low-memory systems (such as aarch64-linux SBCs) can lead to out-of-storage scenarios with the github-runner service because the working directory is set to by default , which is sized to 25% of the system memory by default . Ideally there can be an option to use storage instead of memory for the working directory. I'm opening an issue first because I am not sure if there is a way to work around this already; can the argument in the service be overridden, or is there another way to change for this service with a systemd setting? If there isn't a straightforward solution I can open a PR to add this as an option. Maintainers:
I also experienced issues with no space left on . So far, however, increasing its size did the job. Nevertheless, I'd also appreciate the option to use another filesystem for the runtime directory. We won't be able to use systemd for that as it demands a -like filesystem for the runtime directory.
I guess standard installs avoid this by using the directory. Maybe we should just document how increase size instead of adding another option?
You may pass an arbitrary path to the options of the configuration script. Our module currently always uses the runtime directory systemd assigns to the service.
Yeah, in our case using the runtime directory that provides makes the most sense for dynamic user, again, with documentation on how to increase the size of the runtime directory. Currently our module doesn't support static users so isn't very useful... though I'm guessing our lack of support for static users is an oversight - see details here:
Code change:
, pyinstaller , glibc , binutils <ins> , macholib </ins> , installShellFiles <ins> , stdenv </ins> }: buildPythonPackage rec {

Related discussion:
text: Steps to reproduce the behaviour: PyInstaller on Darwin It fails to build at gcc as gcc is not avlible on macOS CC <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Is it possible that you can make gcc only in linux but clang if pyinstaller uses clang for darwin to use that?
I got it working I am willing to contribute a fix to this.
I will need to some how package since requires it for macos systems.
But first of all since gcc is required on linux is there a possible if linux include gcc instead of clang.
Based on , it seems like and the stuff is only required on linux. Maybe we could just throw in a here? Do you know if more needed to be done to fix the darwin build? Feel free to open a PR if you'd like.
You need which I am looking to make a package for and I think I still have to test if you need . I am looking to make a pr in a couple of days to fix both pyinstaller and package
I think gcc can be replace with clang which is compatible with both linux and darwin.
Macholib is now in a pr:
Now I am looking to fix pyinstaller for darwin.