jiebi/CodeConvo huggingface dataset:
Code change:
ulimit -s 20000 export PYSCF_CONFIG_FILE=$(pwd)/pyscf/pyscf_config.py ''; <del> # As defined for the PySCF CI at https://github.com/pyscf/pyscf/blob/master/.github/workflows/run_tests.sh # minus some additionally numerically instable tests, that are sensitive to BLAS, FFTW, etc. checkPhase = '' runHook preCheck nosetests pyscf/ -v  --exclude-dir=examples --exclude-dir=pyscf/pbc/grad  --exclude-dir=pyscf/x2c  --exclude-dir=pyscf/adc  --exclude-dir=pyscf/pbc/tdscf  -e test_bz  -e h2o_vdz  -e test_mc2step_4o4e  -e test_ks_noimport  -e test_jk_hermi0  -e test_j_kpts  -e test_k_kpts  -e test_lda  -e high_cost  -e skip  -e call_in_background  -e libxc_cam_beta_bug  -e test_finite_diff_rks_eph  -e test_finite_diff_uks_eph  -e test_finite_diff_roks_grad  -e test_finite_diff_df_roks_grad  -e test_frac_particles  -e test_nosymm_sa4_newton  -e test_pipek  -e test_n3_cis_ewald  -e test_veff  -I test_kuccsd_supercell_vs_kpts.py  -I test_kccsd_ghf.py  -I test_h_.*.py  --exclude-test=pyscf/pbc/gw/test/test_kgw_slow_supercell.DiamondTestSupercell3  --exclude-test=pyscf/pbc/gw/test/test_kgw_slow_supercell.DiamondKSTestSupercell3  --exclude-test=pyscf/pbc/gw/test/test_kgw_slow.DiamondTestSupercell3  --exclude-test=pyscf/pbc/gw/test/test_kgw_slow.DiamondKSTestSupercell3  --exclude-test=pyscf/pbc/tdscf/test/test_krhf_slow_supercell.DiamondTestSupercell3  --exclude-test=pyscf/pbc/tdscf/test/test_kproxy_hf.DiamondTestSupercell3  --exclude-test=pyscf/pbc/tdscf/test/test_kproxy_ks.DiamondTestSupercell3  --exclude-test=pyscf/pbc/tdscf/test/test_kproxy_supercell_hf.DiamondTestSupercell3  --exclude-test=pyscf/pbc/tdscf/test/test_kproxy_supercell_ks.DiamondTestSupercell3  -I .*_slow.*py -I .*_kproxy_.*py -I test_proxy.py tdscf/*_slow.py gw/*_slow.py </del> <ins> # Numerically slightly off tests disabledTests = [ "test_tdhf_singlet" "test_ab_hf" "test_ea" "test_bz" "h2o_vdz" "test_mc2step_4o4e" "test_ks_noimport" "test_jk_hermi0" "test_j_kpts" "test_k_kpts" "test_lda" "high_cost" "skip" "call_in_background" "libxc_cam_beta_bug" "test_finite_diff_rks_eph" "test_finite_diff_uks_eph" "test_finite_diff_roks_grad" "test_finite_diff_df_roks_grad" "test_frac_particles" "test_nosymm_sa4_newton" "test_pipek" "test_n3_cis_ewald" "test_veff" "test_collinear_kgks_gga" ]; </ins> <del> runHook postCheck ''; </del> <ins> pytestFlagsArray = [ "--ignore=pyscf/pbc/tdscf" "--ignore=pyscf/pbc/gw" "--ignore-glob=*_slow.*py" "--ignore-glob=*_kproxy_.*py" "--ignore-glob=test_proxy.py" ]; </ins> meta = with lib; { description = "Python-based simulations of chemistry framework";

Related discussion:
text: Steps to reproduce the behavior: See Broke 3 days ago, (also broken for python-3.10 and x86_64-darwin, probably here )
Same issue when trying to run .
Code change:
bazel_0_26 = callPackage ../development/tools/build-managers/bazel/bazel_0_26 { inherit (darwin) cctools; inherit (darwin.apple_sdk.frameworks) CoreFoundation CoreServices Foundation; <del> buildJdk = jdk8; </del> <ins> buildJdk = jdk8_headless; </ins> buildJdkName = "jdk8"; runJdk = jdk11_headless; stdenv = if stdenv.cc.isClang then llvmPackages_6.stdenv else stdenv;

Related discussion:
text: Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify 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. Maintainer information:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in
Code change:
port = 1888; tlsPort = 1889; anonPort = 1890; <ins> bindTestPort = 1891; </ins> password = "VERY_secret"; hashedPassword = "$7$101$/WJc4Mp+I+uYE9sR$o7z9rD1EYXHPwEP5GqQj6A7k4W1yVbePlb8TqNcuOLV9WNCiDgwHOB0JHC1WCtdkssqTBduBNUnUGd6kmZvDSw=="; topic = "test/foo";

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:
<title>Configuring</title> <para> <del> To enable PostgreSQL, add the following to your <filename>configuration.nix</filename>: </del> <ins> To enable PostgreSQL, add the following to your <filename>configuration.nix</filename>: </ins> <programlisting> <xref linkend="opt-services.postgresql.enable"/> = true; <xref linkend="opt-services.postgresql.package"/> = pkgs.postgresql_11; </programlisting> <del> Note that you are required to specify the desired version of PostgreSQL (e.g. <literal>pkgs.postgresql_11</literal>). Since upgrading your PostgreSQL version requires a database dump and reload (see below), NixOS cannot provide a default value for <xref linkend="opt-services.postgresql.package"/> such as the most recent release of PostgreSQL. </del> <ins> Note that you are required to specify the desired version of PostgreSQL (e.g. <literal>pkgs.postgresql_11</literal>). Since upgrading your PostgreSQL version requires a database dump and reload (see below), NixOS cannot provide a default value for <xref linkend="opt-services.postgresql.package"/> such as the most recent release of PostgreSQL. </ins> </para> <!--

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:
<title>Configuring</title> <para> <del> To enable PostgreSQL, add the following to your <filename>configuration.nix</filename>: </del> <ins> To enable PostgreSQL, add the following to your <filename>configuration.nix</filename>: </ins> <programlisting> <xref linkend="opt-services.postgresql.enable"/> = true; <xref linkend="opt-services.postgresql.package"/> = pkgs.postgresql_11; </programlisting> <del> Note that you are required to specify the desired version of PostgreSQL (e.g. <literal>pkgs.postgresql_11</literal>). Since upgrading your PostgreSQL version requires a database dump and reload (see below), NixOS cannot provide a default value for <xref linkend="opt-services.postgresql.package"/> such as the most recent release of PostgreSQL. </del> <ins> Note that you are required to specify the desired version of PostgreSQL (e.g. <literal>pkgs.postgresql_11</literal>). Since upgrading your PostgreSQL version requires a database dump and reload (see below), NixOS cannot provide a default value for <xref linkend="opt-services.postgresql.package"/> such as the most recent release of PostgreSQL. </ins> </para> <!--

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:
''; nextcloud24 = generic { <del> version = "24.0.7"; sha256 = "a1c7344a4eb27260a9f6f6e6f586bdc4fb35e1e9330e1a6e8d46c05634db6384"; </del> <ins> version = "24.0.8"; sha256 = "a5c3a070516debba991355e6b737b261396b15b9f2cd939617611ab0bed99299"; </ins> }; nextcloud25 = generic { <del> version = "25.0.1"; sha256 = "72d4076924caf19139c40178597af6211799e20440ce196fb43b9c4e47d77515"; </del> <ins> version = "25.0.2"; sha256 = "d6ab40faa108937bda42395f570ff111f4c97343b55be1420024da3177e37d59"; </ins> }; # tip: get the sha with:

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: 25.0.1 desired version: 25.0.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.
Code change:
{ lib , stdenv , fetchFromGitHub <ins> , installShellFiles , libiconv , libmpdclient </ins> , meson , ninja , pkg-config <del> , libmpdclient </del> , sphinx <del> , libiconv </del> }: stdenv.mkDerivation rec {

Related discussion:
text: The mpccli package is missing bashcompletion, even though a bash completion file is in the upstream repo under contrib/mpc- . Steps to reproduce the behavior: the package a terminal and type It tries only to complete with the contents of the current directory mpc should be completed with the mpc subcomands like , , etc. On a regular system, the file would have to be installed under /etc/bashcompletion.d/ . I don't know whats the nix(os) equivalent to this.
First, I am not the maintainer of this package. Nonetheless I will review this. Second, in Nixpkgs we do "almost" the same: we use a special hook that installs those extra files at the . Now I need to sleep; please wait a bit more.
Code change:
} for (i = 0; extra_options != NULL && extra_options[i] != NULL; i++) g_ptr_array_add (args, (gchar *) extra_options[i]); <ins> diff --git a/src/builder-utils.c b/src/builder-utils.c index f1c06db5..2e3347c5 100644 </ins> --- a/src/builder-utils.c +++ b/src/builder-utils.c @@ -149,7 +149,7 @@ strip (GError **error,

Related discussion:
text: Describe the bug flatpak-builder for some reasons can't use rofiles-fuse To Reproduce Steps to reproduce the behavior: build any app using flatpak-builder Expected behavior flatpak-builder should use rofiles-fuse. Screenshots Additional context Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(piotrek): nixpkgs: Maintainer information:
installing solve this problem so maybe should be ?
We patch the paths to the executables to be hardcoded, so the program doesn't have to rely on something like ostree being installed. I believe one path isn't hardcoded with the current patch That looks it up in PATH, probably why it was working once you installed it.
cc
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
should fix that issue.
Code change:
wxGTK = wxGTK30; }; <del> buck = callPackage ../development/tools/build-managers/buck { jdk = jdk8; # TODO: remove override https://github.com/NixOS/nixpkgs/pull/89731 }; </del> <ins> buck = callPackage ../development/tools/build-managers/buck { }; </ins> buildkite-agent = buildkite-agent3; buildkite-agent2 = throw "pkgs.buildkite-agent2 has been discontinued. Please use pkgs.buildkite-agent (v3.x)";

Related discussion:
text: Buck as installed via nix reports with an older release version than the one listed in its nixpkgs My guess is that is probably the correct version. The issue here is that IIRC buck Expected behavior 's output should match the version rerefenced in the build file. Notify maintainers
I did try to investigate by bumping buck to its latest release that should be Python3 compatible but didn't get very far as I am unfamiliar with the build system. But maybe the patch helps With this I encountered a failure at the end of the build
buck now generates a hash for build outputs
Code change:
bonzomatic = callPackage ../applications/editors/bonzomatic { }; bottles = callPackage ../applications/misc/bottles { <del> wine = wineWowPackages.minimal; </del> <ins> wine = null; </ins> }; brave = callPackage ../applications/networking/browsers/brave { };

Related discussion:
text: Vulkan/dxvk doesnt work on bottles. Vulkan is working correctly on my laptop as vkcube, vulkaninfo and the game im trying to run on bottles (that i ran thru wineWowPackages.staging + dxvk install from the official archive file) run perfectly. Steps to reproduce the behavior: bottles a bottle for gaming a game. the "directx error" pop up. Also, the dxvk log files say that the "VKKHRsurface" extension failed to load. DXVK/Vulkan should work on bottles. ! Please run and paste the result.
Having the exact same Issue on 22.11pre393800. (Raccoon)
If fails then there is a driver issue. Vulkan wont be able to draw anything to screen without it. When it occurs in proton issues it's usually a missing 32bit Vulkan library. Tho there can ofc probably be other causes
update: using the system wine doesn't fix dxvk either. only running thru the command line does. As i said, running it thru wine on the terminal does work, so something in the bottles thing is not working right.
I found the cause: these hardcoded paths right there: With this extra lines in , Vulkan will work on Bottles: I'm not sure if this is the best way to solve it, though. Tested only on a 64-bit bottle (I don't know if 32-bit bottles need to also link ). .
!!! nice find!
Code change:
bonzomatic = callPackage ../applications/editors/bonzomatic { }; bottles = callPackage ../applications/misc/bottles { <del> wine = wineWowPackages.minimal; </del> <ins> wine = null; </ins> }; brave = callPackage ../applications/networking/browsers/brave { };

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: bottles <!-- 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: 2022.5.28-trento-3 desired version: 2022.7.14-brescia-1 <!-- 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.
While automatic update using was removed by in you need to wait while we will "get auto updates from r-rynatm"
That not true. I removed the over complicated updater in which wasn't necessary at all. Since r-ryantm also uses nix-update there was also no need to replace it. That's wrong. You can always create an update PR yourself by running ` or by manually update the package and create a PR with that. r-ryantm goes through all packages so it can sometimes take a few days until the update PR is created. Also nix-update is very lightweight with minimal dependencies, so there is not really a reason to not use it. It also does not require any kind of token or authentication.
Bottles the version released after the one currently present in nixpkgs, was released on June 13. Over one month has passed, so something about the auto-updater isn't working.
The latest r-ryantm log is here . Not sure why that is not working like it should.
I guess a update script is needed for this case :disappointed: Since the package is using , it HAS a fallback update script , so nixpkgs-update is no longer trying to figure out the latest version itself but just run the script.
Code change:
bonzomatic = callPackage ../applications/editors/bonzomatic { }; bottles = callPackage ../applications/misc/bottles { <del> wine = wineWowPackages.minimal; </del> <ins> wine = null; </ins> }; brave = callPackage ../applications/networking/browsers/brave { };

Related discussion:
text: However seems like cannot handle the version , so it will fail at You may just try Repology gets software latest version from various Linux distributions that ships this app, so since AUR and OpenMandriva have 2022.6.14 (no suffix) the latest version is 2022.6.14. Looks like there is also an related report in Note that nixpkgs-update does not really tries to bump package in this way because it has an fallback update script.
Code change:
You can use `woman` to get completion of all available man pages. For example, type `M-x woman <RET> nixos-rebuild <RET>.` <del> ### Editing DocBook 5 XML Documents {#sec-emacs-docbook-xml} Emacs includes [nXML](https://www.gnu.org/software/emacs/manual/html_node/nxml-mode/Introduction.html), a major-mode for validating and editing XML documents. When editing DocBook 5.0 documents, such as [this one](#book-nixos-manual), nXML needs to be configured with the relevant schema, which is not included. To install the DocBook 5.0 schemas, either add {var}`pkgs.docbook5` to [](#opt-environment.systemPackages) ([NixOS](#sec-declarative-package-mgmt)), or run `nix-env -f '<nixpkgs>' -iA docbook5` ([Nix](#sec-ad-hoc-packages)). Then customize the variable {var}`rng-schema-locating-files` to include {file}`~/.emacs.d/schemas.xml` and put the following text into that file: ::: {.example #ex-emacs-docbook-xml} ### nXML Schema Configuration (`~/.emacs.d/schemas.xml`) ```xml <?xml version="1.0"?> <!-- To let emacs find this file, evaluate: (add-to-list 'rng-schema-locating-files "~/.emacs.d/schemas.xml") --> <locatingRules xmlns="http://thaiopensource.com/ns/locating-rules/1.0"> <!-- Use this variation if pkgs.docbook5 is added to environment.systemPackages --> <namespace ns="http://docbook.org/ns/docbook" uri="/run/current-system/sw/share/xml/docbook-5.0/rng/docbookxi.rnc"/> <!-- Use this variation if installing schema with "nix-env -iA pkgs.docbook5". <namespace ns="http://docbook.org/ns/docbook" uri="../.nix-profile/share/xml/docbook-5.0/rng/docbookxi.rnc"/> --> </locatingRules> ``` ::: </del>

Related discussion:
text: The NixOS manual's section on Emacs has a . It states which is at the very least misleading and potentially confusing since the docbook migration. Either remove these references to the manual being in docbook, or remove the section in its entirety, since (with the completion of the docbook migration) it seems unclear what relevance xml editing in emacs has to NixOS at all, and people interested in the topic will presumably look to other resources elsewhere (e.g. ). (I'd open a PR for either, but am unsure which one to prefer, hence this issue) <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]: