jiebi/CodeConvo huggingface dataset:
Change:
<ins> diff -ru orig/t/sa_compile.t new/t/sa_compile.t --- orig/t/sa_compile.t	2022-12-14 06:03:26.000000000 +0000 +++ new/t/sa_compile.t	2023-06-25 12:30:39.735577152 +0000 @@ -40,7 +40,7 @@ # we now have an "installed" version we can run sa-compile with.  Ensure # sarun() will use it appropriately -$scr = "$instdir/$temp_binpath/spamassassin"; +$scr = "$perl_cmd -T $instdir/$temp_binpath/spamassassin"; $scr_localrules_args = $scr_cf_args = "";      # use the default rules dir, from our "install" &set_rules(' @@ -86,8 +86,8 @@ # ------------------------------------------------------------------- rmtree( glob "~/.spamassassin/sa-compile.cache". { safe => 1 }); # reset test -system_or_die "TMP=$instdir TMPDIR=$instdir $instdir/$temp_binpath/sa-compile --quiet -p $cwd/$workdir/user.cf --keep-tmps -D 2>$instdir/sa-compile.debug";  # --debug -$scr = "$instdir/$temp_binpath/spamassassin"; +system_or_die "TMP=$instdir TMPDIR=$instdir $perl_cmd -T $instdir/$temp_binpath/sa-compile --quiet -p $cwd/$workdir/user.cf --keep-tmps -D 2>$instdir/sa-compile.debug";  # --debug +$scr = "$perl_cmd -T $instdir/$temp_binpath/spamassassin"; $scr_localrules_args = $scr_cf_args = "";      # use the default rules dir, from our "install" %patterns = ( </ins>

Discussion:
SpamAssassin generates and compiles C code from anti-spam rules. This currently fails because the generated code makes use of the function, which is not available during the rule compilation process. Steps to reproduce the behavior: the SpamAssassin service that sa-update.service fails with the error message: that, consequently, spamd.service will not function. Alternatively, the error can also be observed by invoking directly. sa-update.service succeeds <!-- 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.
A smoke-test that serves as a reproducer is available in .
In theory, this could be addressed by making libxcrypt available when compiling rules, but care must probably also be taken so that the dynamic linker can find it at rule run-time.
Rule compilation seems to complete without errors for the rule if we set . However, of course the resulting binary is not linked against libxcrypt then. I’m not sure when Spamassassin will generate code that actually calls functions from that library.
Change:
<del> { stdenv, fetchPypi, buildPythonPackage }: </del> <ins> { stdenv, fetchPypi, buildPythonPackage, fetchpatch }: </ins> buildPythonPackage rec { <del> name = "${pname}-${version}"; </del> pname = "faulthandler"; version = "3.0";

Discussion:
python27Packages.faulthandler fails to build on the unstable channel Cc () The output shows test failures due to regular expressions not matching. E.g. It seems that the tests are expecting to see in the message, while the actual error says . If it's just that, I hope that it would be easy to fix the build. I am happy to help if given some guidance. Full output: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs:
This is an upstream issue. See similar issue Best write them that they should also accept , , etc. Then you can open a PR here that adds a patch to the derivation.
Thanks, will look into that. It probably makes sense to keep this issue open to track the upstream one though.
Note that a patch is available ( ), it may make sense to apply it (e.g. done for Fedora ) while waiting for a new release. I am still happy to try and do that.
I don't think that patch will work. It accepts but not .
Sorry, I missed that :(
I opened an upstream PR: And I applied the patch in Nixpkgs:
fyi has now been merged and a release is pending (see )... hopefully we won't need the patch after that. Thanks everyone for your work!
I removed the patches in .
Change:
cmake, gcc, libtool, <ins> parameterized, </ins> perl, setuptools, simplejson, }: buildPythonPackage rec { pname = "awslambdaric"; <del> version = "2.0.11"; </del> <ins> version = "2.1.0"; </ins> pyproject = true; disabled = isPy27;

Discussion:
Steps to reproduce the behavior: python311Packages.awslambdaric e.g.: I'm using a flake to build a docker image with awslambdaric to deploy in a AWS Lambda. I'm on NixOS unstable. I attempted to override doChecks to false but that did not help. There is a where the simplejson version changed. More recently, upstream has relaxed the version requirements: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks, should fix it.
Change:
<ins> { lib , stdenv , fetchurl , autoPatchelfHook , nixosTests }: let inherit (stdenv.hostPlatform) system; throwSystem = throw "Unsupported system: ${system}"; sources = lib.importJSON ./sources.json; platform = sources.platforms.${system} or throwSystem; inherit (sources) version; inherit (platform) arch hash; in stdenv.mkDerivation { pname = "typesense"; inherit version; src = fetchurl { url = "https://dl.typesense.org/releases/${version}/typesense-server-${version}-${arch}.tar.gz"; inherit hash; }; nativeBuildInputs = [ autoPatchelfHook ]; # The tar.gz contains no subdirectory sourceRoot = "."; installPhase = '' mkdir -p $out/bin cp $sourceRoot/typesense-server $out/bin ''; passthru = { tests = { inherit (nixosTests) typesense; }; updateScript = ./update.sh; }; meta = with lib; { homepage = "https://typesense.org"; description = "Typesense is a fast, typo-tolerant search engine for building delightful search experiences."; license = licenses.gpl3; # There has been an attempt at building this from source, which were deemed # unfeasible at the time of writing this (July 2023) for the following reasons. # - Pre 0.25 would have been possible, but typesense has switched to bazel for 0.25+, #   so the build would break immediately next version # - The new bazel build has many issues, only some of which were fixable: #   - preBuild requires export LANG="C.UTF-8", since onxxruntime contains a #     unicode file path that is handled incorrectly and otherwise leads to a build failure #   - bazel downloads extensions to the build systems at build time which have #     invalid shebangs that need to be fixed by patching rules_foreign_cc through #     bazel (so a patch in nix that adds a patch to the bazel WORKSPACE) #   - WORKSPACE has to be patched to use system cmake and ninja instead of downloaded toolchains #   - The cmake dependencies that are pulled in via bazel at build time will #     try to download stuff via cmake again, which is not possible in the sandbox. #     This is where I stopped trying for now. # XXX: retry once typesense has officially released their bazel based build. sourceProvenance = with sourceTypes; [ binaryNativeCode ]; platforms = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" ]; maintainers = with maintainers; [ oddlama ]; }; } </ins>

Discussion:
Project description Fast, typo tolerant, in-memory fuzzy Search Engine for building delightful search experiences. Metadata homepage URL: source URL: license: gpl3 platforms: linux, darwin
Change:
<ins> diff --git a/util/pandoc.go b/util/pandoc.go index 5dbc58d..5f32644 100644 --- a/util/pandoc.go +++ b/util/pandoc.go @@ -97,6 +97,8 @@ var ( ) func InitPandoc() { +    PandocBinPath = "@pandoc_path@" +    return if ContainerStd != Container { return } </ins>

Discussion:
Project description SiYuan is a privacy-first personal knowledge management system that supports complete offline usage, as well as end-to-end encrypted data sync. Metadata homepage URL: source URL: license: AGPL-3.0 license platforms: unix, linux, darwin, windows Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Looked at the project, looks like it uses for lockfiles, which is unfortunate, as nixpkgs doesn't really support that officially. It also uses custom electron builder configs for different systems, which would complicate it a bit more. (Though, not many other source-built electron apps support anything other than linux) We could put a generated in-tree, but NPM lockfiles take up too much space IMO. I'll make an attempt at getting this to work, though.
I got to this point: (you need to generate your own package-) There are several issues with it, causing it not to be able to launch. The first is that when copying the files from the /nix/store to the workspace, it doesn't make sure to reset the permissions. I tried patching it, but the other method only resets modification times instead of permissions. Relevant files:
Thanks for your work! I'm new to packaging for nix, so I can't help with your problems. I found that Siyuan does publish an , would that maybe be an easier option?
Wouldn't it be easier to just run it with ? But for packaging it there's that can wrap an appimage. but I haven't tried it myself. Edit. sorry I accidentally clicked close with comment instead of comment.
It might be easier, but I've never done so previously, so I'll leave that for someone else.
I tried wraping the appimage. It launches the first time and works properly. but on the second launch it give a couple of errors. and . I think it's the same issue that mentioned. Running makes it work properly.
I think calling on the files copied to the dest should be enough to fix it. right? Would you like to create a pull request for it? It's hard to keep track of things in the comments.
Change:
'' + optionalString (cfg.passwordFile != null) '' export PAPERLESS_ADMIN_USER="''${PAPERLESS_ADMIN_USER:-admin}" <del> export PAPERLESS_ADMIN_PASSWORD=$(cat "${cfg.dataDir}/superuser-password") </del> <ins> export PAPERLESS_ADMIN_PASSWORD=$(cat $CREDENTIALS_DIRECTORY/PAPERLESS_ADMIN_PASSWORD) </ins> superuserState="$PAPERLESS_ADMIN_USER:$PAPERLESS_ADMIN_PASSWORD" superuserStateFile="${cfg.dataDir}/superuser-state"

Discussion:
I want to use but with and residing on an NFS mounted path. My NFS server is secured to only allow access from . I also have enabled on my NFS server, as is the recommended best practice. But the paperless module uses tmpfiles to ensure those directories are created, but root does not have permission to create files in the nfs share. Result: To be clear the nfs mounted path is so and are inside the mount. Notably the paperless service still works, if I ensure those directories exist myself. But the tmpfiles rules setup service still errors out. One workaround I thought might work would be to set and to and then set those env vars myself. However the NixOS module requires those two options to be set. Possible fixes: sub-directories could be created inside a systemd service that is running as the user. this wouldn't work without some shenangiams because if the dir is something like the user won't have permissions to make and optional so the admin can manage setting them this isn't ideal because then the user also has to muck with a flag to bypass the and let the admin manage it themselves. this my favored option I'm happy to open a PR if the maintainers like one of those options. Steps to reproduce the behavior: with and on nfs monts those directories don't exist in the nfs mount should work without error. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
stdenv.mkDerivation rec { name    = "${pname}${if withGnome then "-gnome" else ""}-${version}"; pname   = "NetworkManager-l2tp"; <del> version = networkmanager.version; </del> <ins> version = "1.2.4"; </ins> src = fetchFromGitHub { owner  = "nm-l2tp"; repo   = "network-manager-l2tp"; <del> rev    = "c0cedda5e2a0ded695b497c361eaf577068520cb"; sha256 = "01f39ghc37vw4n4i7whyikgqz8vzxf41q9fsv2gfw1g501cny1j2"; </del> <ins> rev    = "${version}"; sha256 = "1mvn0z1vl4j9drl3dsw2dv0pppqvj29d2m07487dzzi8cbxrqj36"; </ins> }; buildInputs = [ networkmanager ppp libsecret ]

Discussion:
After nixos-rebuild switch, the network-manager service goes down and immediately segfaults every time it tries to come up again. journalctl for the segfault message or something, anyway, at this point I don't have working network anymore. nixos 17.09pre104870.
Specifically it segfaults because returns a non-zero exit status (saying "No for interface NetworkManager"); the segfault itself appears fixes in their HEAD. I haven't checked whether that makes it actually work, yet, but maybe we could arrange for it to have a in the meantime, whatever that means.
In which commit it was fixed?
Does this also happen in 17.03?
Happens with both the 17.03 tag and the 17.03 channel. Looks like cherry-picking the above commit as a patch for our network-manager lets it work correctly, btw.
also fixed in 17.03:
Change:
disk_indicator = callPackage ../os-specific/linux/disk-indicator { }; <ins> displaycal = callPackage ../applications/graphics/displaycal { }; </ins> displaylink = callPackage ../os-specific/linux/displaylink { inherit (linuxPackages) evdi; };

Discussion:
Project description . A few months back the project was removed because Python 2 was removed, and the Pillow lib was insecure too. This project is a revival of the project but under Python 3. In fact they have stated: "Everything should be working now". DisplayCAL is a tool for many color-related tasks; from the docs: Calibration + Characterization (Profiling). Installing the created ICC profile both locally and system-wide (requires root permissions). Profile Info window is now fully working (on some systems we still have an issue related to default values ). Measurement report creation. Creating, displaying and uploading Colorimeter Corrections. Measuring and reporting display uniformity. Creating charts with Test Chart Editor and creating diagnostic 3d data. Creating 3D LUTs. Creating synthetic ICC profiles. Metadata homepage URL: source URL: license: GPL 3.0 platforms: unsure, but at least Linux
Change:
owner = "LaunchPlatform"; repo = "beancount-black"; rev = version; <del> sha256 = "sha256-jhcPR+5+e8d9cbcXC//xuBwmZ14xtXNlYtmH5yNSU0E="; </del> <ins> hash = "sha256-4ooMskwPJJLJBfPikaHJ4xuwR1x478ecYWZdIE0UAK8="; </ins> }; buildInputs = [

Discussion:
Steps to reproduce the behavior: Full build log: This error occurs because the version of in nixpkgs is 0.1.23 and requires a prior version. Setting resolves the build error but leads to a runtime error that crashes the program. There is an but they seem to be rather unresponsive. Everything does work as intended when the version of is manually pinned to 0.1.21.
Change:
inherit configureFlags internalDeps buildInputs zendExtension doCheck; <ins> prePatch = "pushd ../.."; postPatch = "popd"; </ins> preConfigure = '' nullglobRestore=$(shopt -p nullglob) shopt -u nullglob   # To make ?-globbing work

Discussion:
After PR phpExtensions.mysqlnd not supported compression. Checked with
cc
Not supported gzip compression and OpenSSL signatures on phar package before update
Change:
inherit prefix check; modules = modules ++ extraModules ++ baseModules ++ [ pkgsModule ]; args = extraArgs; <ins> specialArgs = { modulesPath = ../modules; }; </ins> }) config options; # These are the extra arguments passed to every module.  In

Discussion:
I'm thinking of bringing this line back: and getting rid of nixos/modules/misc/extra- Does anyone have objections? I fully buy the ability to pass arguments in the module system using , but if it doesn't work (and breaks in a horrible way) for the most common use case ( in imports), that seems bad and the cost of restoring the old way seems pretty low. Anyone have objections? I can make the change if nobody objects. Ideally, I'd like it in 15.06, since it's getting in the way of some work I'm trying to squeeze into 15.06. cc
IMO our only choices are to do this or to set as a prerequisite (perhaps enforced using ) that points there. No strong preference either way.
Yeah, this is probably the best solution.
Cool! Do any of you know of VM tests that would suitably make sure I don't break anything too obvious by making that change? I'd obviously rather not make the change and then discover a week from now that I broke someone's key use case :smile: I'll be making the change this evening at this rate.
Any thoughts on having set using scopedImport? That way stays NixOS-independent. But not a huge difference IMO.
I don't see how adding back could break anything.
Famous last words! :grinning: But I agree, as long as it evaluates at all it's almost certainly fine.
That sounds more complicated than the one-liner suggested by
Change:
lispLibs = oa.lispLibs ++ [ self.sb-cga ]; }); <ins> qlot-cli = build-asdf-system rec { pname = "qlot"; version = "1.5.2"; src = pkgs.fetchFromGitHub { owner = "fukamachi"; repo = "qlot"; rev = "refs/tags/${version}"; hash = "sha256-j9iT25Yz9Z6llCKwwiHlVNKLqwuKvY194LrAzXuljsE="; }; lispLibs = with super; [ archive deflate dexador fuzzy-match ironclad lparallel yason ]; nativeLibs = [ pkgs.openssl ]; nativeBuildInputs = [ pkgs.makeWrapper ]; buildScript = pkgs.writeText "build-qlot-cli" '' (load "${self.qlot-cli.asdfFasl}/asdf.${self.qlot-cli.faslExt}") (asdf:load-system :qlot/command) (asdf:load-system :qlot/subcommands) ;; Use uiop:dump-image instead of sb-ext:dump-image for the image restore hooks (setf uiop:*image-entry-point* #'qlot/cli:main) (uiop:dump-image "qlot" :executable t #+sb-core-compression :compression #+sb-core-compression t) ''; installPhase = '' runHook preInstall mkdir -p $out/bin cp qlot.asd $out rm *.asd cp -r * $out mv $out/qlot $out/bin wrapProgram $out/bin/qlot  --prefix LD_LIBRARY_PATH : $LD_LIBRARY_PATH runHook postInstall ''; meta.mainProgram = "qlot"; }; </ins> }); in packages

Discussion:
If I build the qlot package myself, it installs a shell script in /usr/local/bin/qlot. This script is used in Makefiles to run qlot to install dependencies. I don't see the script in my The contents of the script from my local install: This obviously needs to be updated for Nix, but is beyond my current capabilities. Steps to reproduce the behavior: fails A working shell script named "qlot" is created. <!-- 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.
Change:
type = types.str; default = "us"; description = '' <del> Keyboard layout. </del> <ins> Keyboard layout, or multiple keyboard layouts separated by commas. </ins> ''; };

Discussion:
I just realized that the correct ISO 3166-1 country code for the united kingdom, is actualy . before then, I assumed that something in the interaction between nixoskde was broken and it was impossible to update the locale. weirdly enough, requires and not , but it notifies of an error if you select . Similarly, gives you an error if you select instead of instead silently fails and doesn't change the layout if you specify an incorrect code by mistake
Change:
copyDesktopItems ]; <del> buildInputs = [ dbus ]; </del> <ins> buildInputs = [ dbus stdenv.cc.cc.lib ]; </ins> desktopItems = [ (makeDesktopItem {

Discussion:
My guess is that following commit , some rules/paths have changed and during Cloudfare warp installation, auto-patchelf does not find the file. I've not found a similar report. Sorry if it is a duplicate. Steps to reproduce the behavior: -shell -p cloudfare-warp Cloudfare warp should install. N/A since you're listed as the cloudfare-warp maintainer :)
Change:
python3.pkgs.buildPythonApplication rec { pname = "khal"; <del> version = "0.10.5"; </del> <ins> version = "0.11.1"; </ins> src = fetchFromGitHub { owner = "pimutils"; repo = pname; rev = "v${version}"; <del> hash = "sha256-FneJmoAOb7WjSgluCwlspf27IU3MsQZFKryL9OSSsUw="; </del> <ins> hash = "sha256-5wBKo24EKdEUoYhhv1EqMPOjdwUS31d3R24kLdbyvPA="; </ins> }; SETUPTOOLS_SCM_PRETEND_VERSION = version;

Discussion:
Steps to reproduce the behavior: to the branch Please run and paste the result.
Now it doesn't build on unstable as well. This package is pretty fussy with recurring issues.
This is probably the upstream issue:
Note that this error was fixed by , this issue can probably be closed.
indeed succeeds. Upstream also has an open PR for this issue: Should we keep this issue open to undo when the upstream PR is merged or just close this issue here?
I think closing is fine.
It seems like it started to fail again, with a different set of tests: Maybe we should just disable testing on this package?
Now I have issue with not building either as a dependency. I've had tests disabled for a while to deal with the test failures and it's ran alright.
This is extra annoying because you can't override it with an overlay. because the Python packages use .
You can, using note: I had to add the same overlay for , since it also has problems with tests. Both problems seem to be caused by an update to package
was recently.
Should be fixed by
Change:
packageOverrides = lib.foldr lib.composeExtensions (self: super: { }) ([ (mkOverride "flask"       "0.10.1" "0wrkavjdjndknhp8ya8j850jq7a1cli4g5a93mg8nh1xz2gq50sc") (mkOverride "flask_login" "0.2.11" "1rg3rsjs1gwi2pw6vr9jmhaqm9b3vc9c4hfcsvp4y8agbh7g3mc3") <del> (mkOverride "jinja2"      "2.8.1"  "14aqmhkc9rw5w0v311jhixdm6ym8vsm29dhyxyrjfqxljwx1yd1m") </del> (mkOverride "pylru"       "1.0.9"  "0b0pq0l7xv83dfsajsc49jcxzc99kb9jfx1a1dlx22hzcy962dvi") (mkOverride "sarge"       "0.1.4"  "08s8896973bz1gg0pkr592w6g4p6v47bkfvws5i91p9xf8b35yar") (mkOverride "tornado"     "4.5.3"  "02jzd23l4r6fswmwxaica9ldlyc2p6q8dk6dyff7j58fmdzf853d") # https://github.com/NixOS/nixpkgs/pull/58179#issuecomment-478605134 (mkOverride "werkzeug"    "0.14.1" "c3fd7a7d41976d9f44db327260e263132466836cef6f91512889ed60ad26557c") <ins> # Octoprint holds back jinja2 to 2.8.1 due to breaking changes. # This old version does not have updated test config for pytest 4, # and pypi tarball doesn't contain tests dir anyways. (pself: psuper: { jinja2 = psuper.jinja2.overridePythonAttrs (oldAttrs: rec { version = "2.8.1"; src = oldAttrs.src.override { inherit version; sha256 = "14aqmhkc9rw5w0v311jhixdm6ym8vsm29dhyxyrjfqxljwx1yd1m"; }; doCheck = false; }); }) </ins> ]); };

Discussion:
The tests for python27Packages.jinja2 fail and thereby the derivation fails to evaluate. (Full log below) I'm crosscompiling an aarch64 sd image with . I'm crosscompiling aarch64 with nixpkgs .
I had the same issue too, this fixes it for me.
Fixed by
Change:
dontUnpack = true; dontBuild = true; dontStrip = true; <del> dontWrapQtApps = true; </del> installPhase = '' mkdir -p $out

Discussion:
Describe the bug same with previous versions nixpkgs at nixpkgs at nixpkgs at their download url seems not stable. i got the same file (hash) every time the latest version is 3.10.5. an update should fix it. but stable url would still be good To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Change:
} ''; }; <del> "~ ^/store-apps" = { priority = 201; extraConfig = "root ${cfg.home};"; }; "~ ^/nix-apps" = { priority = 201; extraConfig = "root ${cfg.home};"; }; </del> "^~ /.well-known" = { priority = 210; extraConfig = ''

Discussion:
The extraApp called displays as blank. This was working fine on nextcloud27. Rest of the site is working fine. Steps to reproduce the behavior: am currently on to webpage is blank on: Firefox Chrome Edge It should display the normal forms page. ! Found non-nixos issue relating to it here: Seems it may be a related issue? <!-- 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]: