jiebi/CodeConvo huggingface dataset:
Code change:
# Symlink to bin mkdir -p $out/bin <del> ln -s $out/lib/Signal/signal-desktop $out/bin/signal-desktop </del> <ins> ln -s $out/lib/Signal/signal-desktop $out/bin/signal-desktop-unwrapped </ins> runHook postInstall ''; <ins> # Required for $SQLCIPHER_LIB which contains "/build/" inside the path: noAuditTmpdir = true; </ins> preFixup = '' <ins> export SQLCIPHER_LIB="$out/lib/Signal/resources/app.asar.unpacked/node_modules/better-sqlite3/build/Release/better_sqlite3.node" test -x "$SQLCIPHER_LIB" # To ensure the location hasn't changed </ins> gappsWrapperArgs+=( --prefix LD_LIBRARY_PATH : "${lib.makeLibraryPath [ stdenv.cc.cc ] }" <ins> --prefix LD_PRELOAD : "$SQLCIPHER_LIB" </ins> ${customLanguageWrapperArgs} )

Related discussion:
text: Describe the bug Just lost on two different NixOS machine my Signal Desktop history because of this faulty update... I don't know, probably doesn't make sense for people to downgrade who are already upgraded but for others it dataloss To Reproduce Steps to reproduce the behavior: Signal Desktop Signal Desktop you to delete db, if you interact in a wrong way it will delete your data Notify maintainers ( and
Sorry to hear that. I recently lost my history too... It's really frustrating! Yeah, unfortunately I don't think there's anything we can do about it (as downstream package maintainers). AFAIK the source of the bug is still unknown, it doesn't seem to affect all users, and all releases have a limited lifetime ("expire" 90 days after the release, see my comment in ). Thanks for saying that! This really bothered me too... I just didn't say anything because I was too angry to keep it nice enough. (I raged a bit here but after I realized that one cannot even import old backups I had to take a break.)
I just got hit by a similar issue by moving from Archlinux (encrypted database) to NixOS (non encrypted database). After many things, the easiest fix to ensure proper functionalities IMHO is installing: This will disable tracker3 and prevent SQLite to be loaded in the process which will replace SQLCipher and cause the SQLite3 API to be the original one (i.e. non-encrypted) and cause many issues down the road I guess. That might not fix everything though :upsidedownface: Opened a PR:
FYI, in case anyone has feedback/suggestions: We might merge soon and it should cause another "Database startup error: Error: SQLITE_NOTADB: file is not a database" error (which is really unfortunate but not easily avoidable).
Heads-up: I've just merged to hopefully resolve this once and for all and the Python wrapper script should take care of the database re-encryption when launching Signal-Desktop as usual but the user experience isn't that great and you probably want to backup first in case the script fails unexpectedly.
Thank you, I just upgraded Signal on my computer and the re-encryption did work as intended
Code change:
pname = "flutter"; src = fetchurl { url = "https://storage.googleapis.com/flutter_infra_release/releases/${channel}/linux/${filename}"; <del> sha256 = "12ycz7iasrc9p9c6zr95l6llyji3za43gsx8cmr2kjfiv23bcrv2"; </del> <ins> sha256 = "sha256-sSz/owGdCMB5b9+cAWvLkrfFcIIq5665Xopd4JKv1G4="; </ins> }; patches = getPatches ./patches; };

Related discussion:
text: name: flutter current version: 2.5.1 desired version: 2.8.0 <!-- 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.
done on
Code change:
outputs = [ "out" "dev" "man" ]; <del> patches = [ (substituteAll { src = ./fix-paths.patch; zenity = gnome.zenity; }) ]; </del> src = fetchFromGitHub { owner = "linuxmint"; repo = pname;

Related discussion:
text: Restart cinnamon from the panel freezes the desktop, from the journal you will find cinnamon crashes. click the panel trouble shooting cinnamon No crash.
Okay, I guess I need upstream help for this, going to forward this to upstream...
Code change:
rapidfuzz-cpp ]; <ins> NIX_CFLAGS_COMPILE = lib.optionals (stdenv.cc.isClang && stdenv.isDarwin) [ "-fno-lto"  # work around https://github.com/NixOS/nixpkgs/issues/19098 ]; </ins> propagatedBuildInputs = [ rapidfuzz ];

Related discussion:
text: Steps to reproduce the behavior: python3Packages.rapidfuzz Introduced in . Please run and paste the result.
It appears that cmake selects an incorrect linker. I am currently unsure what's the reason for this. Following I think I might need to set: I have zero experience with nix os + no access to a mac. Is there any way to patch in the build system here to check whether this solves the issue?
Code change:
pathtools = callPackage ../development/python-modules/pathtools { }; <ins> pathvalidate = callPackage ../development/python-modules/pathvalidate { }; </ins> patiencediff = callPackage ../development/python-modules/patiencediff { }; patool = callPackage ../development/python-modules/patool { };

Related discussion:
text: Describe the bug failed to build on master. To Reproduce Steps to reproduce the behavior: nixpkgs master Expected behavior It builds. 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. system: host os: multi-user?: sandbox: version: channels(root): channels(oxa): nixpkgs: Maintainer information:
Code change:
<ins> { lib, stdenv, fetchurl, fetchpatch }: stdenv.mkDerivation rec { pname = "libamplsolver"; version = "20211109"; src = fetchurl { url = "https://ampl.com/netlib/ampl/solvers.tgz"; sha256 = "sha256-LVmScuIvxmZzywPSBl9T9YcUBJP7UFAa3eWs9r4q3JM="; }; patches = [ # Debian provides a patch to build a shared library (fetchpatch { url = "https://sources.debian.org/data/main/liba/libamplsolver/0~20190702-2/debian/patches/fix-makefile-shared-lib.patch"; sha256 = "sha256-96qwj3fLugzbsfxguKMce13cUo7XGC4VUE7xKcJs42Y="; }) ]; installPhase = '' runHook preInstall pushd sys.`uname -m`.`uname -s` install -D -m 0644 *.h -t $out/include install -D -m 0644 *.so* -t $out/lib install -D -m 0644 *.a -t $out/lib popd runHook postInstall ''; meta = with lib; { description = "A library of routines that help solvers work with AMPL"; homepage = "https://ampl.com/netlib/ampl/"; license = [ licenses.mit ]; platforms = platforms.linux; maintainers = with maintainers; [ aanderse ]; }; } </ins>

Related discussion:
text: A clear and concise description of what the bug is. The package doesn't include a folder. I am looking for a version of which includes the executable. Are we building the package incorrectly such that it doesn't include a binary? Any and all help/advice is much appreciated :bow: Steps to reproduce the behavior: output - notice there is no folder A clear and concise description of what you expected to happen. I want the executable. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- might know something about this? :man_shrugging:
was the binary there before On a quick note: I have never used , so I am not familiar with the package. It seems that the package also needs an update:
It appears that the binary requires AMPL, a commercial package, which is not packaged in nixpkgs. See: https://coin-
ah, I understand. Thank you.
Code change:
src = fetchurl { url = "https://www2.ati.com/drivers/linux/radeon-crimson-15.12-15.302-151217a-297685e.zip"; <del> sha256 = "0n0ynqmjkjp5dl5q07as7ps3rlyyn63hq4mlwgd7c7v82ky2skvh"; curlOpts = "--referer http://support.amd.com/en-us/download/desktop?os=Linux+x86_64"; </del> <ins> sha256 = "704f2dfc14681f76dae3b4120c87b1ded33cf43d5a1d800b6de5ca292bb61e58"; curlOpts = "--referer https://www.amd.com/en/support"; </ins> }; hardeningDisable = [ "pic" "format" ];

Related discussion:
text: Maybe it's a problem with the ? Don't seem so. I can also not download it manually with curl: (i get a 0 byte file) But i can download it using a browser from the website. But the hash is also different: So they prevent us from downloading the file using something else than their website. Maybe the referer is not enough now? system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Code change:
(mkFlag true                      "generate-man-pages") ]; <ins> passthru.tests = { nixos-rsyslogd = nixosTests.rsyslogd; }; </ins> meta = { homepage = https://www.rsyslog.com/; description = "Enhanced syslog implementation";

Related discussion:
text: Describe the bug Test  is broken on Master To Reproduce Steps to reproduce the behavior: Expected behavior For the test to pass Additional context I've bisected the problem to this commit:
Thank you for opening this :sparkles:
In that case let's it.
That is weird. How does depend on rsyslog?
This test is kind of flaky, there's some chance I incorrectly bisected it?
I'm bisecting again starting at
going to plug :grin: At a glance I don't see rysyslog having any relation, and likely if the tests are flakey enough bisecting can't give reliable results.
I didn't use that tool because I was bisecting by running the test thrice and only if all fail considering it a bad commit :P
cc. maybe add a flag to :P
That kind of unforseen usecase is exactly why nix-bisect is not just a tool, but a library ;) So you could write your own bisect script in python (a much more pleasant experience than doing so in bash). I may add that feature to the CLI at some poing though, since its probably a pretty common usecase. would probably be a better name, since we really want a minimum number of tries. Feel free to file an issue against :)
I tried bisecting again, but I think this result is also nonsense:
Core of the issue seems to be this:
I don't know &ndash; locally I'm getting this :arrow_up: error even on which (I tried several times).
Careful (manual) bisect lead me to a surprising result: I'll try a few more experiments now. Many my steps failed for other reasons (e.g. libselinux not building), so I suspect that's where you were led astray. I did 2-3 attempts on every step to be surer, but I found no non-determinism on my machine.
I had quite a few steps where the first attempt at building failed, but the second one succeeded, I was bisecting manually with this:
I re-confirmed that reverting that commit atop master () fixes the test for me. (Still no idea why so far.)
cc for the linux config change
Narrowed down just to the kernel option. I don't know... maybe the JIT has some bad interaction with the VM.
Code change:
(mkFlag true                      "generate-man-pages") ]; <ins> passthru.tests = { nixos-rsyslogd = nixosTests.rsyslogd; }; </ins> meta = { homepage = https://www.rsyslog.com/; description = "Enhanced syslog implementation";

Related discussion:
text: For now I suppose I'll push a revert of that single option, unless someone suggests a better idea very soon.
Sounds good to me
Code change:
sed -i '0,/from numpy.distutils.core/s//import setuptools;from numpy.distutils.core/' setup.py ''; <ins> # First test: RuntimeWarning: Mean of empty slice. # Second: SyntaxError: invalid syntax. Due to wrapper? # Third: test checks permissions prePatch = '' substituteInPlace scipy/stats/tests/test_stats.py --replace "test_chisquare_masked_arrays" "remove_this_one" rm scipy/linalg/tests/test_lapack.py substituteInPlace scipy/weave/tests/test_catalog.py --replace "test_user" "remove_this_one" ''; </ins> inherit (support) preBuild checkPhase; <ins> patches = [../development/python-modules/scipy-0.16.1-decorator-fix.patch]; </ins> setupPyBuildFlags = [ "--fcompiler='gnu95'" ]; meta = {

Related discussion:
text: As noted by scipy uses the wrong tests. Instead of running its own test-suite, it runs that of numpy. This is because accidentally pkgName was set to in
Most errors are which are harmless according to
The 12 errors that are encountered are in fact 11 deprecation warnings, and one syntax error in a test when setting PYTHONPATH.
Code change:
<ins> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-custom-packages"> <title>Adding Custom Packages</title> <para> It’s possible that a package you need is not available in NixOS. In that case, you can do two things. First, you can clone the Nixpkgs repository, add the package to your clone, and (optionally) submit a patch or pull request to have it accepted into the main Nixpkgs repository. This is described in detail in the <link xlink:href="https://nixos.org/nixpkgs/manual">Nixpkgs manual</link>. In short, you clone Nixpkgs: </para> <programlisting> $ git clone https://github.com/NixOS/nixpkgs $ cd nixpkgs </programlisting> <para> Then you write and test the package as described in the Nixpkgs manual. Finally, you add it to <xref linkend="opt-environment.systemPackages" />, e.g. </para> <programlisting language="bash"> environment.systemPackages = [ pkgs.my-package ]; </programlisting> <para> and you run <literal>nixos-rebuild</literal>, specifying your own Nixpkgs tree: </para> <programlisting> # nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs </programlisting> <para> The second possibility is to add the package outside of the Nixpkgs tree. For instance, here is how you specify a build of the <link xlink:href="https://www.gnu.org/software/hello/">GNU Hello</link> package directly in <literal>configuration.nix</literal>: </para> <programlisting language="bash"> environment.systemPackages = let my-hello = with pkgs; stdenv.mkDerivation rec { name = &quot;hello-2.8&quot;; src = fetchurl { url = &quot;mirror://gnu/hello/${name}.tar.gz&quot;; sha256 = &quot;0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6&quot;; }; }; in [ my-hello ]; </programlisting> <para> Of course, you can also move the definition of <literal>my-hello</literal> into a separate Nix expression, e.g. </para> <programlisting language="bash"> environment.systemPackages = [ (import ./my-hello.nix) ]; </programlisting> <para> where <literal>my-hello.nix</literal> contains: </para> <programlisting language="bash"> with import &lt;nixpkgs&gt; {}; # bring all of Nixpkgs into scope stdenv.mkDerivation rec { name = &quot;hello-2.8&quot;; src = fetchurl { url = &quot;mirror://gnu/hello/${name}.tar.gz&quot;; sha256 = &quot;0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6&quot;; }; } </programlisting> <para> This allows testing the package easily: </para> <programlisting> $ nix-build my-hello.nix $ ./result/bin/hello Hello, world! </programlisting> </section> </ins>

Related discussion:
text: This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.
Code change:
<ins> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-custom-packages"> <title>Adding Custom Packages</title> <para> It’s possible that a package you need is not available in NixOS. In that case, you can do two things. First, you can clone the Nixpkgs repository, add the package to your clone, and (optionally) submit a patch or pull request to have it accepted into the main Nixpkgs repository. This is described in detail in the <link xlink:href="https://nixos.org/nixpkgs/manual">Nixpkgs manual</link>. In short, you clone Nixpkgs: </para> <programlisting> $ git clone https://github.com/NixOS/nixpkgs $ cd nixpkgs </programlisting> <para> Then you write and test the package as described in the Nixpkgs manual. Finally, you add it to <xref linkend="opt-environment.systemPackages" />, e.g. </para> <programlisting language="bash"> environment.systemPackages = [ pkgs.my-package ]; </programlisting> <para> and you run <literal>nixos-rebuild</literal>, specifying your own Nixpkgs tree: </para> <programlisting> # nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs </programlisting> <para> The second possibility is to add the package outside of the Nixpkgs tree. For instance, here is how you specify a build of the <link xlink:href="https://www.gnu.org/software/hello/">GNU Hello</link> package directly in <literal>configuration.nix</literal>: </para> <programlisting language="bash"> environment.systemPackages = let my-hello = with pkgs; stdenv.mkDerivation rec { name = &quot;hello-2.8&quot;; src = fetchurl { url = &quot;mirror://gnu/hello/${name}.tar.gz&quot;; sha256 = &quot;0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6&quot;; }; }; in [ my-hello ]; </programlisting> <para> Of course, you can also move the definition of <literal>my-hello</literal> into a separate Nix expression, e.g. </para> <programlisting language="bash"> environment.systemPackages = [ (import ./my-hello.nix) ]; </programlisting> <para> where <literal>my-hello.nix</literal> contains: </para> <programlisting language="bash"> with import &lt;nixpkgs&gt; {}; # bring all of Nixpkgs into scope stdenv.mkDerivation rec { name = &quot;hello-2.8&quot;; src = fetchurl { url = &quot;mirror://gnu/hello/${name}.tar.gz&quot;; sha256 = &quot;0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6&quot;; }; } </programlisting> <para> This allows testing the package easily: </para> <programlisting> $ nix-build my-hello.nix $ ./result/bin/hello Hello, world! </programlisting> </section> </ins>

Related discussion:
text: This tracks the conversion of from Docbook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.
I opened a PR for and : PTAL, thanks in advance for reviewing :-)
Code change:
<del> { lib, buildFHSUserEnv, steam </del> <ins> { stdenv, lib, writeScript, buildFHSUserEnv, steam , steam-runtime, steam-runtime-i686 ? null </ins> , withJava ? false , withPrimus ? false , nativeOnly ? false

Related discussion:
text: This weekend I tried these games, all deadlocked in the menu or character selection. Nyheim Oh...Sir! The Insult Simulator Reigns Unturned (free to play) You don't have to be worried to waste money in case you want to test a game. I have had no problem when requesting refunds, just go to I have played these games and found no issues with them: Dota 2 Counter-Strike TIS-100 World of goo Faster Than Light You Must Build a Boat Risk of Rain System: (NixOS: , Ubuntu/Fedora: , ...) 03pre99759. (Gorilla) Nix version: (run ) nix-env (Nix) 1.11.6 Nixpkgs version: (run ) "17.03pre99759." Integrated graphics card, 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
This is normal with steam on nixos unfortunately. There are many steam games that don't work for various reasons, unfortunately many linux steam game developers only make sure their games run on ubuntu and don't really care about relying only on dependencies from the steam runtime. Some games don't play nice with certain graphics cards or drivers as well. If you want to get a particular game working (I can list 150 games that work under nixos with nvidia card and drivers at least) then you'll need to do some work, or at least post any relevant logs from the game/steam so people can actually help you solve the problem. That is assuming that they own the game. :)
There's a slowly-growing list of extra dependencies in the Steam package. If you can figure out what's missing, you can add it there; e.g. as in
I don't have enough motivation to actually buy games for the sole purpose of fixing them and then refunding, sorry. Nevertheless, I'm happy to help if you can post logs and/or s -- those two are the most helpful for determining FHS-related problems.
Code change:
}; in buildPythonPackage ( rec { name = "numpy-${version}"; <del> version = "1.10.1"; </del> <ins> version = "1.10.2"; </ins> src = pkgs.fetchurl { url = "mirror://sourceforge/numpy/${name}.tar.gz"; <del> sha256 = "8b9f453f29ce96a14e625100d3dcf8926301d36c5f622623bf8820e748510858"; </del> <ins> sha256 = "23a3befdf955db4d616f8bb77b324680a80a323e0c42a7e8d7388ef578d8ffa9"; </ins> }; disabled = isPyPy;  # WIP

Related discussion:
text: As noted by scipy uses the wrong tests. Instead of running its own test-suite, it runs that of numpy. This is because accidentally pkgName was set to in
Most errors are which are harmless according to
The 12 errors that are encountered are in fact 11 deprecation warnings, and one syntax error in a test when setting PYTHONPATH.
Code change:
buildInputs = [ qtbase <ins> rtaudio_6 </ins> rtmidi ] ++ lib.optionals stdenv.hostPlatform.isLinux [ qtwayland ] ++ lib.optionals (lib.versionAtLeast qtbase.version "6.0") [ qt5compat <del> ] ++ rtaudio.buildInputs; </del> <ins> ]; </ins> qmakeFlags = [ <del> # we don't have RtAudio 6 yet: https://github.com/NixOS/nixpkgs/pull/245075 # "CONFIG+=system_rtaudio" </del> <ins> "CONFIG+=system_rtaudio" </ins> "CONFIG+=system_rtmidi" ];

Related discussion:
text: Package name: Latest released version: 5.2.0 Current version on the unstable channel: 5.2.0 Current version on the stable/release channel: 5.2.0 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Pending on
Code change:
warnings.warn("NIXOS_INSTALL_GRUB env var deprecated, use NIXOS_INSTALL_BOOTLOADER", DeprecationWarning) os.environ["NIXOS_INSTALL_BOOTLOADER"] = "1" <ins> # flags to pass to bootctl install/update bootctl_flags = [] if "@canTouchEfiVariables@" != "1": bootctl_flags.append("--no-variables") if "@graceful@" == "1": bootctl_flags.append("--graceful") </ins> if os.getenv("NIXOS_INSTALL_BOOTLOADER") == "1": # bootctl uses fopen() with modes "wxe" and fails if the file exists. if os.path.exists("@efiSysMountPoint@/loader/loader.conf"): os.unlink("@efiSysMountPoint@/loader/loader.conf") <del> flags = [] if "@canTouchEfiVariables@" != "1": flags.append("--no-variables") if "@graceful@" == "1": flags.append("--graceful") subprocess.check_call(["@systemd@/bin/bootctl", "--esp-path=@efiSysMountPoint@"] + flags + ["install"]) </del> <ins> subprocess.check_call(["@systemd@/bin/bootctl", "--esp-path=@efiSysMountPoint@"] + bootctl_flags + ["install"]) </ins> else: # Update bootloader to latest if needed available_out = subprocess.check_output(["@systemd@/bin/bootctl", "--version"], universal_newlines=True).split()[2]

Related discussion:
text: During systemd-boot update step attempts to touch EFI variables, even when is set to . Steps to reproduce the behavior: NixOS 21.05 with systemd-boot and to NixOS 21.11 () switch fails with: An error is just an indication of update trying to touch EFI variables. (I have EFI vars touching disabled on that system because of some unrelated firmware breakage) Manually running properly finishes, further switches work fine. systemd-boot update should not touch EFI variables during upgrade. <!-- 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. Maintainer information:
I had a similar issue which I fixed by running "sudo nixos-rebuild --install-bootloader switch"
The fix for this got reverted in