jiebi/CodeConvo huggingface dataset:
Change:
<ins> From 777be9c46c4caed5f3fcde65b70ada4d773f4298 Mon Sep 17 00:00:00 2001 From: Sarah Clark <seclark@nextquestion.net> Date: Sat, 24 Aug 2024 11:26:30 -0700 Subject: [PATCH] Unpin setuptools --- pyproject.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pyproject.toml b/pyproject.toml index d17d12dc8..6bf1c7a38 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -54,7 +54,7 @@ scalene = "scalene.__main__:main" [build-system] build-backend = "setuptools.build_meta" requires = [ -    "setuptools>=65.5.1,<71.0", # Pin to setuptools<71.0 to avoid this bug: https://github.com/pypa/setuptools/issues/4496 +    "setuptools>=65.5.1", "setuptools_scm>=8", "wheel", "cython", -- </ins>

Discussion:
Steps to reproduce the behavior: python312Packages.scalene Per , this failure is intentional due to some behaviour changes in setuptools. I'm not completely familiar with the change or setuptools overall, but the gist seems to be that setuptools now "prefers installed dependencies over vendored ones", whatever that means in this case. fails on () Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
EDIT: Filed a PR to fix this in Scalene.
As soon as Emery has a fix on his end, we can bump the version number or apply the patch. Edit: Watch this PR
Updated in the original sources. We need Emery to cut a new release of Scalene as we're building from the published binary. (The scalene source build is complicated.)
FYI, I managed to make source builds work. That will make future bug responses quicker.
Change:
# Install completions post-install nativeBuildInputs = [ installShellFiles ]; <del> buildInputs = lib.optionals stdenv.isDarwin [ libobjc Security CoreServices Metal Foundation ]; </del> <ins> buildInputs = lib.optionals stdenv.isDarwin [ libiconv libobjc Security CoreServices Metal Foundation ]; </ins> # The rusty_v8 package will try to download a `librusty_v8.a` release at build time to our read-only filesystem # To avoid this we pre-download the file and place it in the locations it will require it in advance

Discussion:
Describe the bug Library is not found when linking on macos. To Reproduce Execute resulting in following output: Expected behavior Deno builds without errors on macos. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(suraj): nixpkgs: Maintainer information:
Change:
export DATABASE_PASSWORD="$(<"${cfg.dbpassFile}")" '' + '' export DATABASE_URL="${dbUrl}" <del> ${cfg.package}/bin/notify_push '${cfgN.datadir}/config/config.php' </del> <ins> exec ${cfg.package}/bin/notify_push '${cfgN.datadir}/config/config.php' </ins> ''; serviceConfig = { User = "nextcloud";

Discussion:
When configuring notifypush for nextcloud the service almost always fails the first time after rebooting the system and requires to be restarted in order to be started successfully. It seems the problem is that notifypush has not finished starting before nextcloud-notifypush-post-start is executed, resulting in a missing or not connected . Steps to reproduce the behavior: notifypush the system (un)lucky and watch nextcloud-notifypush.service` fail service (done automatically) The service starts successfully the first time. Relevant log lines: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I have noticed a similar behavior when the module it was introduced. But i was so far happy with the restart situation. I have played a bit with the situation. I am currently applying the following additional configs to my nextcloud. I think the problem is, that notify_push creates the used socket at start, and we are to early executing the ExecStartPost command to configure. When we let systemd take care for the socket, i could mitigate that and after that i had problems that my acme certificate reload was running in the mean time. After adding nginx-config-reload it was able to run on first try after reboot. You could check if that is also helping on your end and if yes we could check what make sense to use in the module.
I am not sure if this is a good idea since existing Unix sockets are on server startup (and shutdown), possibly interfering with the socket management of SystemD. I don't know why the connection succeeds after restart or when the socket provided by SystemD is replaced by another socket by notifypush, but I think a more robust way to implement this is to set which would delay the execution of until the server signals that it is ready. However something like this would require support by upstream, I could work on a pull request. Edit: After doing some testing it seems that for notifying SystemD to work notify_push has to be the main process of the service, which can be arranged easily by using in the start script.
Doesn't have the program call sdnotify for that to work? I did not find something like that on the code base. here the notify section claims something like that.

Tho I fully agree that the socket is likely not a good idea when notifypush nukes the socket file. Edit: NVM you mentioned a upstream pr for such a function , which I seem to have over read when reading my mail notification.
Change:
{ callPackage , libsForQt5 <ins> , python311 </ins> }: let mkGui = args: callPackage (import ./gui.nix (args)) { inherit (libsForQt5) wrapQtAppsHook; <ins> python3 = python311; </ins> }; mkServer = args: callPackage (import ./server.nix (args)) { };

Discussion:
Steps to reproduce the behavior: gns3-gui-2.2.47 Add any other context about the problem here. <!-- 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]:
seems to have the same issues as
cc
Change:
<del> { stdenv, fetchgit, pkgconfig, which, qtbase, qtsvg, qttools, qtwebkit }: </del> <ins> { stdenv, fetchgit, pkgconfig, which, qtbase, qtsvg, qttools, qtwebkit}: </ins> let <del> version = "0.53.0"; </del> <ins> version = "1.2.0"; </ins> in stdenv.mkDerivation { name = "notepadqq-${version}"; src = fetchgit { url = "https://github.com/notepadqq/notepadqq.git"; <del> rev = "3b0751277fb268ec72b466b37d0f0977c536bc1b"; sha256 = "0hw94mn2xg2r58afvz1xg990jinv9aa33942zgwq54qwj61r93hi"; </del> <ins> rev = "ab074d30e02d49e0fe6957c1523e7fed239aff7d"; sha256 = "0j8vqsdw314qpk5lrgccm9n7gbyr14ac3s65sl1qn87pxhrz1hpg"; </ins> fetchSubmodules = true; };

Discussion:
Hi, Notepadqq 1.2.0 is out, I have tried to bump the version in the , along with the git revision hash, of course, so that I could start a pull request, but the build failed (i.e. running from within the notepadqq subdirectory of this repo) with the error: Thanks for your time
Go to the root of the repo, and execute .
Worked. Forget my deleted comment, I forgot to update the hash. I'll file that pull request.
Change:
]; outputs = [ "out" "dev" "demos" ]; <ins> patches = [ ./rev-file.patch ]; postUnpack = '' # Hack so a version header can be generated. Relies on ./rev-file.patch to work. mkdir -p "$sourceRoot/external/glslang/External" echo "${spirv-tools.src.rev}" > "$sourceRoot/external/glslang/External/spirv-tools" ''; </ins> preConfigure = '' checkRev() { [ "$2" = $(cat "external_revisions/$1_revision") ] || (echo "ERROR: dependency $1 is revision $2 but should be revision" $(cat "external_revisions/$1_revision") && exit 1) } <del> checkRev spirv-tools "${spirv-tools.src.rev}" checkRev spirv-headers "${spirv-tools.headers.rev}" </del> checkRev glslang "${glslang.src.rev}" '';

Discussion:
Tried to make a system upgrade, got this: Obviously, upgrade can't be completed. have in . run Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
This looks like the offending line: This could be related to what file system you are using?
Actually this looks like unrelated to glslang. Works on master:
Change:
${optionalString (symbolsFile  != null) "cp '${symbolsFile}'  'symbols/${name}'"} ${optionalString (typesFile    != null) "cp '${typesFile}'    'types/${name}'"} <del> # patch makefiles for type in compat geometry keycodes symbols types; do if ! test -f "$type/${name}"; then continue fi test "$type" = geometry && type_name=geom || type_name=$type ${ed}/bin/ed -v $type/Makefile.am <<EOF /''${type_name}_DATA = a ${name}  . w EOF ${ed}/bin/ed -v $type/Makefile.in <<EOF /''${type_name}_DATA = a ${name}  . w EOF done </del> # add model description ${ed}/bin/ed -v rules/base.xml <<EOF /</modelList>

Discussion:
I use the following listing in to install a custom keyboard layout: This refers to files in the following structure: This worked until recently (last updated a few months ago), but now fails to build: <details<summaryFull trace</summary</detailsCommenting out the line causes the same error but for . Adding in plausible files in the suggested places also doesn't fix the issue. Steps to reproduce the behavior: up the configuration as above. . The system successfully builds, and I have access to the custom layout. <!-- 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.
Sorry, I forgot to notify maintainers, but I think it's just
This breakage happened with with the update of as they have switched to the meson build system.
Thanks, that's really helpful! I suppose I'll revert to before that merge for now (though I'm finding it hard to find the list of good commit hashes). Do you know any other workarounds?
You can use . that does not have those changes. For a list you can look at in the "Input changes" column. That is a log of the "nixos-unstable" branch, for which the binary cache has been filled after a few tests have been run.
The script that patches the makefile to include the extra layouts need to be updated.
Can you test if your layouts work correctly with ? I a test for a basic file but I haven't tried other types.
Works fine for me but I also only use symbols
Fix merged, you can track the progress to nixos-unstable .
Change:
# to remove them if they are stale let contentDirs = map dirOf contentFiles; <ins> # Multiple "split" parity files can be specified in a single # "parityFile", separated by a comma. # https://www.snapraid.it/manual#7.1 splitParityFiles = map (s: splitString "," s) parityFiles; </ins> in unique ( <del> attrValues dataDisks ++ parityFiles ++ contentDirs </del> <ins> attrValues dataDisks ++ splitParityFiles ++ contentDirs </ins> ); } // optionalAttrs touchBeforeSync { ExecStartPre = "${pkgs.snapraid}/bin/snapraid touch";

Discussion:
When specifying multiple paths in a single parityFile entry (SnapRAID ), the systemd service failes with the following error: Steps to reproduce the behavior: a SnapRAID config and specify a entry like so: run the snapraid sync: the error: The runs without error. SnapRAID has a where you can specify "split" parity files. This is useful when you're using 16tb or bigger ext4-formatted disks for parity. ext4 doesn't support files bigger than 16tb so this "split parity file" can be used to specify two parity files on a single raid disk and SnapRAID will automatically use the second file when the first cannot grow anymore (hits 16TB). You specify these multiple files by putting multiple comma-separated paths in the . This mostly already works except when it comes to the scheduled systemd sync job where it specifies . If you specify a parity with multiple files you'll get an error when the systemd job runs: It seems like since SnapRAID essentially does not allow commas in the parity file paths it would be OK to split on comma here? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
isUnfree (lib.lists.toList attrs.meta.license) && !allowUnfreePredicate attrs; <del> allowInsecureDefaultPredicate = x: builtins.elem x.name (config.permittedInsecurePackages or []); </del> <ins> allowInsecureDefaultPredicate = x: builtins.elem (getName x) (config.permittedInsecurePackages or []); </ins> allowInsecurePredicate = x: (config.allowInsecurePredicate or allowInsecureDefaultPredicate) x; hasAllowedInsecure = attrs:

Discussion:
Describe the bug would raise an unrelated error when trying to use an insecure package: To Reproduce Steps to reproduce the behavior: any package marked with in system.packages (e.g. evilvte); Expected behavior An error stating the package is insecure, or allows the package to be used if it is in . Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(cheng): nixpkgs:
I stumbled upon this too while upgrading from 19.03 today. For me it was due to the package. Diabling the resolved the issue for now. system: host os: multi-user?: sandbox: version: channels(root): channels(cheng): nixpkgs:
Packages used to have to specify a attribute to , more recently seems to have developed the ability to assemble one from the and attributes, so many packages now don't specify directly. It appears that in hasn't yet grown the ability to handle these packages and instead operates on a copy of this attr taken before its has been generated. Edit: think I've spotted the problem. PR incoming.
Should this be closed? The commit message of seems like it, but doesn't use one of Githubs key words.
I can confirm this issue has been resolved
Change:
stdenv.mkDerivation rec { pname = "wl-mirror"; <del> version = "0.8.1"; </del> <ins> version = "0.9.2"; </ins> src = fetchFromGitHub { owner = "Ferdi265"; repo = "wl-mirror"; rev = "v${version}"; <del> hash = "sha256-P5rvZPpIStlOSGj3PaiXAMPWqgWpkC+4IrixEMwoGJU="; </del> <ins> hash = "sha256-W/8DApyd7KtrOrP7Qj6oPKXxLrVzHDuIMOdg+k5ngr4="; </ins> }; patchPhase = ''

Discussion:
<!-- 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: wl-mirror <!-- 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: 0.8.1 desired version: 0.9.2 <!-- 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.
updated desired version to 0.9.2.
(opened PR )
Change:
''; homepage = "https://wasmer.io/"; license = licenses.mit; <del> maintainers = with maintainers; [ Br1ght0ne ]; </del> <ins> maintainers = with maintainers; [ Br1ght0ne shamilton ]; </ins> }; }

Discussion:
name: wasmer current version: 1.0.2 desired version: 2.0.0 maintainers: Please tag this issue in your PR.
Change:
buildPythonPackage rec { pname = "zope-hookable"; <del> version = "5.0.1"; </del> <ins> version = "5.1.0"; </ins> src = fetchPypi { pname = "zope.hookable"; inherit version; <del> sha256 = "0hc82lfr7bk53nvbxvjkibkarngyrzgfk2i6bg8wshl0ly0pdl19"; </del> <ins> sha256 = "8fc3e6cd0486c6af48e3317c299def719b57538332a194e0b3bc6a772f4faa0e"; </ins> }; checkInputs = [ zope_testing ];

Discussion:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- 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.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
lib.warn "blender-with-packages is deprecated in favor of blender.withPackages, e.g. `blender.withPackages(ps: [ ps.foobar ])`" (blender.withPackages (_: args.packages)).overrideAttrs (lib.optionalAttrs (args ? name) { pname = "blender-" + args.name; }); # Added 2023-10-30 <ins> blockbench-electron = blockbench; # Added 2024-03-16 </ins> bluezFull = throw "'bluezFull' has been renamed to/replaced by 'bluez'"; # Converted to throw 2023-09-10 bookletimposer = throw "bookletimposer has been removed from nixpkgs; upstream unmaintained and broke with pypdf3"; # Added 2024-01-01 boost168 = throw "boost168 has been deprecated in favor of the latest version"; # Added 2023-06-08

Discussion:
Package name: blockbench-electron Latest released version: 4.9.3 <!-- Search your package here: --- Current version on the unstable channel: 4.8.1 Current version on the stable/release channel: 4.8.1 <!-- 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. --Misc: Noticed this when trying to enter a nix shell with this package, resulting in an electron-25.9.0 EOL error. Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Okay, so I took a look at updating blockbench to a version with uses and but it looks like after 2 seconds, electron crashes. It's probably got to do something with , but I don't have much experience with it. Tried to debug it with , but it didn't really show me anything helpful. I even tried packaging from source, but it has the same issue.
Okay, so I did some more testing, and it looks like itself is the issue, and above work fine. I'll make a PR with the update.
Change:
cpupower = callPackage ../os-specific/linux/cpupower { }; <ins> displaylink = callPackage ../os-specific/linux/displaylink { }; </ins> dpdk = callPackage ../os-specific/linux/dpdk { }; pktgen = callPackage ../os-specific/linux/pktgen { };

Discussion:
DisplayLink, as far as I can tell, seems to be unfortunately emerging as the only choice for connecting external monitors to laptops without display ports (for example, via the ). It would be great if NixOS could support it. I have no idea what is involved in this. There is an Ubuntu driver. DisplayLink the company claims that it should be possible to port (). The says it's difficult to get working.
Do you have hardware for testing this? The driver itself seems fairly straightforward and I could help packaging it.
I do - I have the Dell adapter linked above.
Change:
buildPythonPackage rec { pname = "gradio-client"; <del> version = "0.14.0"; format = "pyproject"; </del> <ins> version = "0.16.1"; pyproject = true; </ins> disabled = pythonOlder "3.8";

Discussion:
Steps to reproduce the behavior: Gradio / Gradio Client <!-- 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]:
fix for py311
Change:
}; patches = [ <ins> # https://github.com/pdfminer/pdfminer.six/pull/1027 (fetchpatch2 { name = "fix-dereference-MediaBox.patch"; url = "https://github.com/pdfminer/pdfminer.six/pull/1027/commits/ad101c152c71431a21bfa5a8dbe33b3ba385ceec.patch?full_index=1"; excludes = [ "CHANGELOG.md" ]; hash = "sha256-fsSXvN92MVtNFpAst0ctvGrbxVvoe4Nyz4wMZqJ1aw8="; }) </ins> (substituteAll { src = ./disable-setuptools-git-versioning.patch; inherit version;

Discussion:
Steps to reproduce the behavior: . the following errors: This is due to a bug in pdfminer-six. With its six-month release cycle, its downstream derivations will continue to fail for a long time. See There is a patch available at For : For : cc: relative to jupyter-lab <!-- 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]:
Verified -- the patch worked!
Change:
<ins> From d734d03862d7dcc776bd2fa3ba662cdd5879b32e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= <ppisar@redhat.com> Date: Wed, 12 Jul 2023 17:55:27 +0200 Subject: [PATCH] Adapt to perl 5.37.1 Perl 5.37.1 removed a deprecated sv_nv() macro and SDL fails to build with Perl 5.38.0: lib/SDLx/Controller/Interface.xs:60:26: error: implicit declaration of function 'sv_nv' 60 |         out->dv_x      = sv_nv(temp); |                          ^~~~~ Users are advised to use SvNVx() macro instead. SvNVx() seems to have been available all the time (it predates a commit from 1993-10-07). This patch does that. https://github.com/PerlGameDev/SDL/issues/303 --- src/SDLx/Controller/Interface.xs | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/SDLx/Controller/Interface.xs b/src/SDLx/Controller/Interface.xs index 3dc202b7..d326c885 100644 --- a/src/SDLx/Controller/Interface.xs +++ b/src/SDLx/Controller/Interface.xs @@ -57,15 +57,15 @@ void evaluate(SDLx_Interface *obj, SDLx_Derivative *out, SDLx_State *initial, fl SV *temp; temp           = av_pop(accel); -	out->dv_x      = sv_nv(temp); +	out->dv_x      = SvNVx(temp); SvREFCNT_dec(temp); temp           = av_pop(accel); -	out->dv_y      = sv_nv(temp); +	out->dv_y      = SvNVx(temp); SvREFCNT_dec(temp); temp           = av_pop(accel); -	out->dang_v    = sv_nv(temp); +	out->dang_v    = SvNVx(temp); SvREFCNT_dec(temp); SvREFCNT_dec((SV *)accel); @@ -90,15 +90,15 @@ void evaluate_dt(SDLx_Interface *obj, SDLx_Derivative *out, SDLx_State *initial, SV *temp; temp           = av_pop(accel); -	out->dv_x      = sv_nv(temp); +	out->dv_x      = SvNVx(temp); SvREFCNT_dec(temp); temp           = av_pop(accel); -	out->dv_y      = sv_nv(temp); +	out->dv_y      = SvNVx(temp); SvREFCNT_dec(temp); temp           = av_pop(accel); -	out->dang_v    = sv_nv(temp); +	out->dang_v    = SvNVx(temp); SvREFCNT_dec(temp); SvREFCNT_dec((SV *)accel); </ins>

Discussion:
Steps to reproduce the behavior: frozen-bubble works fine on NixOS 23.05. It’s just NixOS Unstable that’s affected. <!-- 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.
Looks like caused by Perl removing a deprecated function; probably requires a cherrypick of
Change:
fi ''; <del> nix.nrBuildUsers = mkDefault (lib.max 32 cfg.maxJobs); </del> <ins> nix.nrBuildUsers = mkDefault (lib.max 32 (if cfg.maxJobs == "auto" then 0 else cfg.maxJobs)); </ins> users.users = nixbldUsers;

Discussion:
Describe the bug A clear and concise description of what the bug is. setting nix.maxJobs = "auto"; Causes nix.nrBuildUsers = mkDefault ( 32 cfg.maxJobs); to fail. To Reproduce Steps to reproduce the behavior: nix.maxJobs ="auto" in you nixos config it ... Expected behavior A clear and concise description of what you expected to happen. You should be able to set nix.maxJobs to auto to saturate your cpu cores. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(colin): channels(root): nixpkgs: Maintainer information: