jiebi/CodeConvo huggingface dataset:
Code change:
<ins> diff --git a/gnucash/price-quotes.scm b/gnucash/price-quotes.scm index 8e3ff255f..a6b805fa5 100644 --- a/gnucash/price-quotes.scm +++ b/gnucash/price-quotes.scm @@ -44,7 +44,7 @@ (define (start-program) (set! program (gnc-spawn-process-async -         (list "perl" "-w" gnc:*finance-quote-check*) #t))) +         (list gnc:*finance-quote-check*) #t))) (define (get-sources) (when program @@ -119,7 +119,7 @@ (define (start-quoter) (set! quoter -        (gnc-spawn-process-async (list "perl" "-w" gnc:*finance-quote-helper*) #t))) +        (gnc-spawn-process-async (list gnc:*finance-quote-helper*) #t))) (define (get-quotes) (when quoter </ins>

Related discussion:
text: On NixOS 22.05, getting financial quotes in gnucash no longer works because the helper scripts are now binary wrappers, but gnucash calls so this fails. Commit suggests that should avoid this, but for some reason the scripts still get wrapped with binaries. NixOS 22.05..
I can reproduce this on my machine from nixpkgs/master, so it's not a 22.05 problem. Interestingly, when I backport GnuCash's derivation from nixpkgs/master back to a known-good commit (), things appear ok. I'll continue digging.
... I see you yourself as a maintainer. Any interest in taking a stab at this? Per I think we're being broken by a change somewhere related to .
... I see you yourself as a maintainer. Any interest in taking a stab at this? still getting my head together after a bad bout of covid, not sure I'll be able to work on anything serious any time soon
I worked around this on my nixos config by adding a patch () to execute the helpers directly without calling out to perl. It seems to work for me. Will this break anything? If desired, I can submit a PR with this patch. Also, the perl helpers seem to be getting wrapped explicitly () is this not the reason the perl helpers are getting wrapped with binary executables?
Code change:
++ optional langAda ../gnat-cflags.patch ++ optional langFortran ../gfortran-driving.patch ++ optional (targetPlatform.libc == "musl" && targetPlatform.isPower) ../ppc-musl.patch <del> ++ optional (!crossStageStatic && targetPlatform.isMinGW) (fetchpatch { url = "https://raw.githubusercontent.com/lhmouse/MINGW-packages/${import ../common/mfcgthreads-patches-repo.nix}/mingw-w64-gcc-git/9000-gcc-${majorVersion}-branch-Added-mcf-thread-model-support-from-mcfgthread.patch"; sha256 = "1in5kvcknlpi9z1vvjw6jfmwy8k12zvbqlqfnq84qpm99r0rh00a"; }); </del> <ins> # Obtain latest patch with ../update-mcfgthread-patches.sh ++ optional (!crossStageStatic && targetPlatform.isMinGW) ./Added-mcf-thread-model-support-from-mcfgthread.patch; </ins> /* Cross-gcc settings (build == host != target) */ crossMingw = targetPlatform != hostPlatform && targetPlatform.libc == "msvcrt";

Related discussion:
text: Describe the bug is when building for MinGW, however an equivalent GCC 10 patch file doesn't exist. I tried looking for a GCC 10 patch on the master branch of , but the folder that contained the patches no longer exists. GCC9 is still currently the default on master, but this will break everything under MinGW the next time staging-next is merged to master. See Support for was originally in To Reproduce Steps to reproduce the behavior: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(kira): nixpkgs: Maintainer information:
It has been moved to to upstream migration. Neither of these repos is stable; their master branches are constantly rebased on upstream and force-pushed.
Code change:
... </screen> </para> <para> <del> To add plugins via NixOS configuration, set <literal>services.postgresql.extraPlugins</literal>: </del> <ins> To add plugins via NixOS configuration, set <literal>services.postgresql.extraPlugins</literal>: </ins> <programlisting> <xref linkend="opt-services.postgresql.package"/> = pkgs.postgresql_11; <xref linkend="opt-services.postgresql.extraPlugins"/> = with pkgs.postgresql_11.pkgs; [

Related discussion:
text: to newer version to different directory as under postgresql user Output I get:
The NixOS service module for PostgreSQL, for some unfathomable reason, initializes new databases using a non-standard superuser role name ( instead of ). This makes it a nightmare to get to work right, so forget that. Instead: back to your old version of postgresql root, dump your entire database to a file somewhere: to the new version of postgresql root, read in the database dump: (you'll likely see an error go by about the role already existing, you can ignore this) For good measure I went and tested this upgrading a 9.2 database to 9.4 under NixOS, worked fine, the applications using it continued on as normal after the import. That said, the real issue here is: why are we initializing databases using a non-standard install / superuser role name?
cc
See regarding the superuser role name.
Shouldn't we switch the default user to "postgres" on new databases and keep the "root" account around for existing-ones ? See
I strongly agree we should switch the default superuser to . Currently, it seems impossible to use to upgrade postgresql databases due to NixOS using the superuser: simply refuses to run as root.
The approach given by above doesn't work for me:
I can submit the change as a PR but don't use postgresql and it needs testing. Feel free to steal it and do the upgrade process with it.
pgdumpall tends to e pretty useless if you database isn't tiny_ :(
that would be a good start :)
there you go :)
FYI: I've just tested migrating 9.2 to 9.6 using and it works flawlessly.
Ok, I think I found out why wasn't working for me, like I mentioned in It seems to be due to this line in the Hydra module: If I change the mapping to then the command works fine. But I'm not exactly sure what are the implications of doing this, or why was mapped to in the first place...
In case someone runs into the same issue as me, I am documenting the procedure I used to upgrade a PostgreSQL database that was being used (only) for Hydra.
Code change:
... </screen> </para> <para> <del> To add plugins via NixOS configuration, set <literal>services.postgresql.extraPlugins</literal>: </del> <ins> To add plugins via NixOS configuration, set <literal>services.postgresql.extraPlugins</literal>: </ins> <programlisting> <xref linkend="opt-services.postgresql.package"/> = pkgs.postgresql_11; <xref linkend="opt-services.postgresql.extraPlugins"/> = with pkgs.postgresql_11.pkgs; [

Related discussion:
text: I tried to follow procedure above, but as I mentioned before, to use as suggested I needed to change the PostgreSQL user mapping in the Hydra module as specified in my comment just above this one, otherwise I would get a message. However, to read the database dump back into the new PostgreSQL installation I had to change the user mapping as follows: ... and then, after activating the configuration, I needed to run the command in the following way (as root): After doing this, the upgrade from PostgreSQL 9.4 to 9.6 seems to have completed successfully.
Related
If anyone else stumbles on this, pgupgrade seems to work now. I realized after upgrade that my db got reinitialized, so steps for me were much more brutish than that post, but in a nutshell: with new postgresql running, clear whatever got reinitialized (pgupgrade won't run if there are data around, but won't tell you what to remove... lists databases, don't know how to list users, I guessed) drop database whatever; drop user whatever; stop postgresql.service figure path for old binaries, e.g. and copy it somewhere. run the actual pgupgrade as user: restart the postgresql service if all went well after some testing pgupgrade suggests removing the old db with (disclaimer: Don't blame me if that eats your data)
Code change:
a stable URL for Nixpkgs to use to package this proprietary software. </para> </listitem> <ins> <listitem> <para> The GRUB specific option <option>boot.loader.grub.extraInitrd</option> has been replaced with the generic option <option>boot.initrd.secrets</option>. This option creates a secondary initrd from the specified files, rather than using a manually created initrd file. </para> </listitem> </ins> </itemizedlist> </section>

Related discussion:
text: Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.
Code change:
sha256 = "sha256-m1UhyjD5ydSgCTBu6sECLlxFx0rnQxFnBA7frbdUqU8="; }; <ins> patches = [ # sss: use BN_set_word(x, 0) instead of BN_zero(), fixes build issue with different versions of openssl (fetchurl { url = "https://github.com/latchset/clevis/commit/ee1dfedb9baca107e66a0fec76693c9d479dcfd9.patch"; sha256 = "sha256-GeklrWWlAMALDLdnn6+0Bi0l+bXrIbYkgIyI94WEybM="; }) ]; </ins> postPatch = '' for f in $(find src/ -type f); do grep -q "/bin/cat" "$f" && substituteInPlace "$f" 

Related discussion:
text: The package 18 on master failed to build. Steps to reproduce the behavior: build github:nixos/nixpkgs#clevis ! Full build log:
Code change:
}; }.${stdenv.system} or (throw "Unsupported system: ${stdenv.system}"); <del> nativeBuildInputs = [ dpkg makeWrapper autoPatchelfHook ]; </del> <ins> nativeBuildInputs = [ dpkg makeWrapper autoPatchelfHook wrapGAppsHook ]; </ins> buildInputs = [ libXtst libXScrnSaver gtk3 nss alsaLib ]; runtimeDependencies = [ udev.lib libnotify ];

Related discussion:
text: Describe the bug A clear and concise description of what the bug is. Rambox apps cause rambox to crash when attempting to upload a file. It gives the message: To Reproduce Steps to reproduce the behavior: rambox rambox in terminal any app that has file upload functionality (I tested Google Messages, Element, and Slack) to upload file Expected behavior Rambox apps should be able to upload files from filesystem Additional context I've seen from browsing other issues that this has been solved before for riot-desktop at first by adding gsettings schema to the package wrapper but currently fixed by using in electron. However, for some reason this did not fix the issue in Rambox. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. these paths will be fetched (0.05 MiB download, 0.28 MiB unpacked): /nix/store/d43v6bx7r6fcaq3fbbfd5mwh1f5s7rmg-bash-interactive-4.4-p23-dev copying path '/nix/store/d43v6bx7r6fcaq3fbbfd5mwh1f5s7rmg-bash-interactive-4.4-p23-dev' from ''... system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Add wrapGAppsHook to
Code change:
@getopt@/bin/getopt --test > /dev/null && rc=$? || rc=$? if [[ $rc -ne 4 ]]; then # This shouldn't happen. <del> echo "Warning: Enhanced getopt not supported, please open an issue." >&2 </del> <ins> echo "Warning: Enhanced getopt not supported, please open an issue in nixpkgs." >&2 </ins> else # Define all short and long options. SHORT=hvidrcas

Related discussion:
text: libgtop is not reproducible, since it embed the output of into one of its binaries. See or build on 2 machines with different kernel versions. Report attached since r13y will not keep it, I think: libgtop build should be reproducible. This patch works from a nixpkgs perspective: However, it should ideally be reported and fixed upstream. N/A Maintainer information:
I marked this as stale due to inactivity. &rarr;
Code change:
--replace "boto3>=1.20,<1.25.0" "boto3~=1.20" ''; <del> nativeBuildInputs = [ setuptools ]; </del> propagatedBuildInputs = [ apispec boto3

Related discussion:
text: Steps to reproduce the behavior: localstack (from unstable) (version 3.2.0) localstack 2.3.0 works and so does (tagged because you bumped the version) (the channel is slightly messed up. I am using 23.11 but with flakes) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The new version requires too many dependencies to package up in a reasonable time frame and even includes circular ones. contains a revert to 3.0.0 which builds for me and shows the usage. Can you take a look if that works for you?
Sorry for the delay! Yes, the revert works well for me! Thank you!
Code change:
pytestCheckHook ]; <del> preCheck = '' </del> <ins> preCheck = let fontsConf = makeFontsConf { fontDirectories = [ ]; }; in '' </ins> export HOME=$(mktemp -d) <ins> export FONTCONFIG_FILE=${fontsConf}; </ins> # For tests/test_misc.py::test_autostart mkdir -p $HOME/.config/autostart <del> export QT_PLUGIN_PATH="${qt5.qtbase.bin}/${qt5.qtbase.qtPluginPrefix}" </del> <ins> export QT_PLUGIN_PATH="${qtbase}/${qtbase.qtPluginPrefix}" </ins> export QT_QPA_PLATFORM=offscreen ''; disabledTestPaths = [ <del> "tests/test_archives.py" "tests/test_borg.py" "tests/test_lock.py" "tests/test_notifications.py" ]; disabledTests = [ "diff_archives_dict_issue-Users" "diff_archives-test" "test_repo_unlink" "test_repo_add_success" "test_ssh_dialog" "test_create" "test_scheduler_create_backup" </del> <ins> # QObject::connect: No such signal QPlatformNativeInterface::systemTrayWindowChanged(QScreen*) "tests/test_excludes.py" "tests/integration" "tests/unit" </ins> ]; meta = with lib; { <del> changelog = "https://github.com/borgbase/vorta/releases/tag/v0.8.10"; </del> <ins> changelog = "https://github.com/borgbase/vorta/releases/tag/${src.rev}"; </ins> description = "Desktop Backup Client for Borg"; homepage = "https://vorta.borgbase.com/"; license = licenses.gpl3Only;

Related discussion:
text: Package name: vorta Latest released version: 0.9.1 <!-- Search your package here: --- Current version on the unstable channel: 0.8.12 Current version on the stable/release channel: 0.8.12 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
sha256 = "sha256-1KnYHz9ntKbgfLeoDcsQrV6RdvzDB2LHCoFYCmS4sLY="; }; <ins> patches = [ # https://savannah.gnu.org/bugs/?func=detailitem&item_id=62436 ./patches/bug62436.patch ]; </ins> buildInputs = [ readline ncurses

Related discussion:
text: For example: fails similarly. The line that causes the failure according to my testing is: A list of some packages that didn't break: Could be this is an upstream issue.
So digging into it, this is an issue raised by Octave's package management system itself. Namely, this -statement from Line 80 in that file is the statement. It expects to remove a file, which is not existing. The reason the other packages did not break was because they either do not have a directory () or they actually do have a generated file (netcdf & control). You can technically solve this by adding an empty script to the directory. I manually did this, and the package built correctly again. As for why this change happened, I cannot tell. The particular statement shown did not change between 6.4.0 and 7.1.0 in the file.
Looks like
That's the exact issue. Seems like we will need to wait for upstream to fix it. How does this usually get handled
Seems like we should apply to the patch:
There are still 5 packages failing to build, but that is a lot fewer than before.
Code change:
Restart = "always"; # Filesystem <del> ProtectSystem = "strict"; </del> ProtectHome = true; <del> PrivateTmp = true; </del> PrivateDevices = true; ProtectKernelTunables = true; ProtectKernelModules = true;

Related discussion:
text: Describe the bug gitea fails to start due to a too restrictive systemd setup To Reproduce Looks like is a bit too restrictive. :smile:
ping
Removing the blacklist of and gets us past the test, I think, but there's still problems with the socket.
Judging from this error output: it looks like it fails in prescript during in Interestingly enough, there is a right underneath that, in which does not seem to be the issue. This does not look like an issue with Gitea itself, since it fails during the service pre script. Since the and will only be run if the configuration is managed by nix, the tests pass if I set in the test config. (unfortunatly I don't know much about systemd services and especially systemd sanboxing, so I'm not sure if the information from above is useful or not)
Any chance the service is broken too? I recently updated and service failed to start. I haven't dug into it yet... I may have seen something about a database permission issue.
Temporary fix for someone who using bleeding-edge Gitea:
This doesn't solve the issue for me. I get the following output:
Pretty strange. It works for me (). You can try to disable it at all () and if it'll still not work then just change in the same way all other parameters to default values that were introduced in . p.s. probably there's must be something like a mkForceRemove, but I haven't found anything in manual.
Ok the fix is actually working, I just had an own AmbientCapabilities definition in my configuration which didn't play nicely with the new options.
Code change:
# TODO: package meek https://support.torproject.org/glossary/meek/ meek = "/meek-not-available"; in rec { <del> onionshare = buildPythonApplication { </del> <ins> onionshare = python3.pkgs.buildPythonApplication { </ins> pname = "onionshare-cli"; inherit version; src = "${src}/cli";

Related discussion:
text: Steps to reproduce the behavior: onionshare <!-- 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]:
The package distutils was remove in Python 3.12. Depends on upsteam. I raised a PR for the fix:
Code change:
{lib, stdenv, fetchurl}: stdenv.mkDerivation rec { <del> version = "1.3.1"; </del> <ins> version = "1.4"; </ins> pname = "commons-fileupload"; src = fetchurl { url    = "mirror://apache/commons/fileupload/binaries/${pname}-${version}-bin.tar.gz"; <del> sha256 = "1jy7w2j2ay56mpq4ij3331cf9zgpkm832ydr63svb35j0ymnky72"; </del> <ins> sha256 = "1avfv4gljp7flra767yzas54vfb6az9s1nhxfjv48jj2x0llxxkx"; </ins> }; installPhase = '' tar xf ${src} mkdir -p $out/share/java <del> cp lib/*.jar $out/share/java/ </del> <ins> cp commons-fileupload-*-bin/*.jar $out/share/java/ </ins> ''; meta = {

Related discussion:
text: , CVSSv3=9.8 (nixos-20.03, nixos-unstable) CVSSv3=7.5 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
needs 1.3.2 for CVE-2016- needs 1.3.1 for CVE-2016-3092
Code change:
wantedBy = [ "multi-user.target" ]; environment = { <del> JAVA_HOME = "${pkgs.jre}"; </del> <ins> # JRE 15 removed option `UseConcMarkSweepGC` which is needed. JAVA_HOME = "${pkgs.jre8}"; </ins> HBASE_LOG_DIR = cfg.logDir; };

Related discussion:
text: After enable HBase module , and rebuild. The service unit cannot start, it says JVM option not exists. Steps to reproduce the behavior: HBase by adding config . , it should be failed. shows VM option is Unrecognized. I found the same issues on the StackOverFlow, it seems jre 15 dropped the option: I fixes this by adding this line, but it should be fixed in module. I can do the fixes PR if you want. Maintainer information:
go for it. I'm also not maintaining this anymore, so may be best to also remove from .
Code change:
echo "doc manual $dest manual.html" >> $out/nix-support/hydra-build-products echo "doc manual $dest nixpkgs-manual.epub" >> $out/nix-support/hydra-build-products ''; <ins> # Environment variables PANDOC_LUA_FILTERS_DIR = "${pkgs.pandoc-lua-filters}/share/pandoc/filters"; </ins> }

Related discussion:
text: Describe the bug To contribute to the nixpkgs documentation I followed the instructions in the nixpkgs manual "Chapter 21. Contributing to this documentation" and I followed the code snippet Firstly I was greeted with some warnings: But moving on to I saw a large number of errors. It looks like is set up inside the nix-shell but it's not picked up by ? Running the command does work. To Reproduce Expected behavior No warnings, no errors. Metadata Please run and paste the result. Maintainer information:
nix-shell has a specific setup to allow running stdenv phases such as
That also gives me a bunch of errors as well, but different ones: For a bunch of files. I managed to write some updates to the docs and validated them just using the command, but it's a bit unfortunate that just following the instructions literally doesn't work.
Sorry about that. should fix it.
Thanks, that fixes it for me (tested by setting the env variable manually). Great to see these steps towards making it easier to contribute to the docs.
Code change:
<ins> { lib, rustPlatform, fetchFromGitHub, pkg-config, cargo, rustc, clippy, makeWrapper, }: let pname = "rustlings"; version = "6.2.0"; in rustPlatform.buildRustPackage { inherit pname version; src = fetchFromGitHub { owner = "rust-lang"; repo = "rustlings"; rev = "v${version}"; hash = "sha256-BVmiMIIx8YEO57FO0ZpsCQcim68mn7NHpAOO86dZqlI="; }; cargoHash = "sha256-ZupwPw/bfeN+s7IWXbY21K/ODXSaYef+IDDpBVCi3Ek="; # Disabled test that does not work well in an isolated environment checkFlags = [ "--skip=run_compilation_success" "--skip=run_test_success" ]; nativeBuildInputs = [ pkg-config makeWrapper ]; postFixup = '' wrapProgram $out/bin/rustlings --suffix PATH : ${ lib.makeBinPath [ cargo rustc clippy ] } ''; meta = { description = "Explore the Rust programming language and learn more about it while doing exercises"; homepage = "https://rustlings.cool/"; changelog = "https://github.com/rust-lang/rustlings/releases"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ luftmensch-luftmensch ]; mainProgram = "rustlings"; }; } </ins>

Related discussion:
text: Project description This project is used by programmers looking to explore the Rust programming language and learn more about it while doing exercises. These exercises are meant to get you comfortable with the language itself and its features. Metadata homepage URL: source URL: license: MIT platforms: MacOS, Linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Interesting package request. But does it make sense given that you need to modify the rustling files in order to use it? I personally used the that's included in the project. which I think are removed in the new release :(
Take a look at . The maintainer of rustlings explained why the was removed.
TL;DR: All required files are embedded in the binary now. The exercises are dumped on initialization. I am the new author. If you need any help, don't hesitate to ping me. Note that a new version was published yesterday.
Code change:
https://github.com/AndrewRadev/switch.vim/,, https://github.com/simrat39/symbols-outline.nvim/,, https://github.com/vim-syntastic/syntastic/,, <ins> https://github.com/ziontee113/syntax-tree-surfer/,HEAD, </ins> https://github.com/nanozuki/tabby.nvim/,HEAD, https://github.com/kdheepak/tabline.nvim/,, https://github.com/vim-scripts/tabmerge/,,

Related discussion:
text: Project description <!-- Describe the project a little: --Syntax Tree Surfer is a plugin for Neovim that helps you surf through your document and move elements around using the nvim-treesitter API. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: