jiebi/CodeConvo huggingface dataset:
Code change:
<del> --- old/build/pkgs/python2/spkg-install	2015-07-26 15:34:43.000000000 +0200 +++ new/build/pkgs/python2/spkg-install	2015-09-16 20:48:51.904555797 +0200 @@ -32,7 +32,7 @@ done # We are setting LDFLAGS so that we pick up Sage's readline -LDFLAGS="-L$SAGE_LOCAL/lib $LDFLAGS" +LDFLAGS="-L$SAGE_LOCAL/lib -lcrypt $LDFLAGS" export LDFLAGS if [ "$SAGE_DEBUG" = "yes" ]; then </del>

Related discussion:
text: Since Sage is huge and complicated, I figured I would make this issue to collaboratively track progress and share branches. One big issue is that Sage 7 , instead they use some with scant documentation . has the correct SHA256 for Sage 7.6 and updates a patch file. It currently fails when Sage tries to build . Some nice things to do for the future: ) cc:
thanks for picking this up
Me myself being a miserable loser who has failed to update Sage in the past, I hope you succeed… My attempt hit the following wall. It is unbearably slow to let Sage build everything, but when I had convinced it to use the system versions of majority of dependencies it began to complain cryptically about their interaction in some case.
Can you elaborate? Do you have a branch that has that work? Also, to be clear: I probably don't have the skills or time to upgrade Sage by myself, I was hoping that if we shared our knowledge and de-duplicated efforts we might be able to get closer together
I think it was 6-dot-something; it required a metric ton of adding options to the packages in NixPkgs (I have pushed that all to master long ago), and the Sage tricks are most likely too version-specific. It was long enough ago that I have since abandoned and lost the changes.
In case anybody in here is still waiting for this: I got sage to compile and run. I'm currently trying to minimize the dependencies and check that everything is working correctly (there is one doctest failure, but it was mentioned multiple times in the mailing list and apperas to be harmles -- just a timeout). I'll probably make a PR in the next couple of days.
Code change:
<del> --- old/build/pkgs/python2/spkg-install	2015-07-26 15:34:43.000000000 +0200 +++ new/build/pkgs/python2/spkg-install	2015-09-16 20:48:51.904555797 +0200 @@ -32,7 +32,7 @@ done # We are setting LDFLAGS so that we pick up Sage's readline -LDFLAGS="-L$SAGE_LOCAL/lib $LDFLAGS" +LDFLAGS="-L$SAGE_LOCAL/lib -lcrypt $LDFLAGS" export LDFLAGS if [ "$SAGE_DEBUG" = "yes" ]; then </del>

Related discussion:
text: Sage needs texlive-core-2014, which is deprecated. Run with modern nixpkgs (i.e. from git) System: NixOS: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version:
Code change:
<del> { lib , stdenv , cmake , llvm , fetchFromGitHub , mbedtls , gtk3 , pkg-config , capstone , dbus , libGLU , glfw3 , file , perl , python3 , jansson , curl , fmt_8 , nlohmann_json , yara , rsync </del> <ins> { lib, stdenv, cmake, llvm, fetchFromGitHub, mbedtls, gtk3, pkg-config, capstone, dbus, libGLU, libGL, glfw3, file, perl, python3, jansson, curl, fmt_8, nlohmann_json, yara, rsync, autoPatchelfHook, </ins> }: let <del> version = "1.33.2"; patterns_version = "1.33.2"; </del> <ins> version = "1.35.3"; patterns_version = "1.35.3"; </ins> patterns_src = fetchFromGitHub { <ins> name = "ImHex-Patterns-source-${patterns_version}"; </ins> owner = "WerWolv"; repo = "ImHex-Patterns"; rev = "ImHex-v${patterns_version}"; <del> hash = "sha256-5a6aFT8R8vMzPS+Y+fcDV5+olhioEpLjdMqa7qOyGsw="; </del> <ins> hash = "sha256-h86qoFMSP9ehsXJXOccUK9Mfqe+DVObfSRT4TCtK0rY="; </ins> }; in

Related discussion:
text: Imhex on unstable and nixos-24.05 crashes. Output from the above command: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same as pending to merge
Ah, sorry, I only searched in opened issues.
Code change:
<del> { lib , stdenv , cmake , llvm , fetchFromGitHub , mbedtls , gtk3 , pkg-config , capstone , dbus , libGLU , glfw3 , file , perl , python3 , jansson , curl , fmt_8 , nlohmann_json , yara , rsync </del> <ins> { lib, stdenv, cmake, llvm, fetchFromGitHub, mbedtls, gtk3, pkg-config, capstone, dbus, libGLU, libGL, glfw3, file, perl, python3, jansson, curl, fmt_8, nlohmann_json, yara, rsync, autoPatchelfHook, </ins> }: let <del> version = "1.33.2"; patterns_version = "1.33.2"; </del> <ins> version = "1.35.3"; patterns_version = "1.35.3"; </ins> patterns_src = fetchFromGitHub { <ins> name = "ImHex-Patterns-source-${patterns_version}"; </ins> owner = "WerWolv"; repo = "ImHex-Patterns"; rev = "ImHex-v${patterns_version}"; <del> hash = "sha256-5a6aFT8R8vMzPS+Y+fcDV5+olhioEpLjdMqa7qOyGsw="; </del> <ins> hash = "sha256-h86qoFMSP9ehsXJXOccUK9Mfqe+DVObfSRT4TCtK0rY="; </ins> }; in

Related discussion:
text: Imhex failed to start. Steps to reproduce the behavior: -shell -p imhex --run imhex Shows the following errors: Imhex start up normally. Adding -v, --verbose doesn't give more information. I don't know how to either.
Maintainer ping:
Can repro on master, but can't repro if I checkout and build from it, it should be possible to bisect and find out at what point this broke.
First bad commit: <details<summarygit bisect log</summary</details
Seems there's a bunch of upstream reports of breakage with glfw 3.4
This might be fixed with The PR was merged into 1.90.6, but 1.33.2 contains a vendored 1.90.4, which doesn't contain the fix. My guess is that updating from the current 1.33.2 in nixpkgs to the latest version upstream (1.35.3 as of today) should fix the issue, as the latter contains a vendored updated to version 1.90.8, which should contain the fix.
Looks like the PR was closed, are you talking about instead?
Yes, sorry. I got the PR reference from: ... which also references the commit you mentioned.
Still crashes on imhex 1.35.3, which I more or less expected.
After applying both PRs and , finally works on my system with the current . Note: both PRs were needed, either one alone didn't fix all the issues for me.
Solved, marking as closed.
Code change:
<ins> { lib , buildPythonPackage , btrfs-progs }: buildPythonPackage { pname = "btrfsutil"; inherit (btrfs-progs) version src; format = "setuptools"; buildInputs = [ btrfs-progs ]; preConfigure = '' cd libbtrfsutil/python ''; # No tests doCheck = false; pythonImportsCheck = [ "btrfsutil" ]; meta = with lib; { description = "Library for managing Btrfs filesystems"; homepage = "https://btrfs.wiki.kernel.org/"; license = licenses.lgpl21Plus; maintainers = with maintainers; [ raskin lopsided98 ]; }; } </ins>

Related discussion:
text: Python module, corresponding to the package and exposing its functionality in Python programs, fails to import, despite being included in . module is imported successfully. n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- (as maintainer) (as the one who exposed the Python bindings) Please run and paste the result.
Note: it seems like the module doesn't work even on commits that introduced it properly... To verify, run in a Nixpkgs checkout:
Yeah, I screwed up testing this. btrfs-progs doesn't propagate python, so I was using my system (non-NixOS) Python installation without noticing. should fix it.
Code change:
(fetchNuGet { pname = "System.Net.Http"; version = "4.3.0"; sha256 = "1i4gc757xqrzflbk7kc5ksn20kwwfjhw9w7pgdkn19y3cgnl302j"; }) (fetchNuGet { pname = "System.Net.NameResolution"; version = "4.3.0"; sha256 = "15r75pwc0rm3vvwsn8rvm2krf929mjfwliv0mpicjnii24470rkq"; }) (fetchNuGet { pname = "System.Net.Primitives"; version = "4.3.0"; sha256 = "0c87k50rmdgmxx7df2khd9qj7q35j9rzdmm2572cc55dygmdk3ii"; }) <del> (fetchNuGet { pname = "System.Net.Security"; version = "4.3.2"; sha256 = "1aw1ca1vssqrillrh4qkarx0lxwc8wcaqdkfdima8376wb98j2q8"; }) </del> <ins> (fetchNuGet { pname = "System.Net.Security"; version = "4.3.0"; sha256 = "1aa5igz31ivk6kpgsrwck3jccab7wd88wr52lddmgypmbh9mmf87"; }) </ins> (fetchNuGet { pname = "System.Net.Sockets"; version = "4.3.0"; sha256 = "1ssa65k6chcgi6mfmzrznvqaxk8jp0gvl77xhf1hbzakjnpxspla"; }) (fetchNuGet { pname = "System.Net.WebHeaderCollection"; version = "4.3.0"; sha256 = "0ms3ddjv1wn8sqa5qchm245f3vzzif6l6fx5k92klqpn7zf4z562"; }) (fetchNuGet { pname = "System.Net.WebSockets"; version = "4.3.0"; sha256 = "1gfj800078kggcgl0xyl00a6y5k4wwh2k2qm69rjy22wbmq7fy4p"; })

Related discussion:
text: Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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:
nativeBuildInputs = [ pkgconfig ]; buildInputs = [ <del> curl </del> <ins> curl zlib </ins> ] ++ stdenv.lib.optionals stdenv.isDarwin [ CoreServices Security ]; cargoBuildFlags = [ "--features no-self-update" ]; patches = lib.optionals stdenv.isLinux [ <del> (runCommand "0001-dynamically-patchelf-binaries.patch" { CC=stdenv.cc; patchelf = patchelf; } '' </del> <ins> (let libPath = lib.makeLibraryPath [ zlib # libz.so.1 ]; in (runCommand "0001-dynamically-patchelf-binaries.patch" { CC=stdenv.cc; patchelf = patchelf; libPath = "$ORIGIN/../lib:${libPath}"; } '' </ins> export dynamicLinker=$(cat $CC/nix-support/dynamic-linker) substitute ${./0001-dynamically-patchelf-binaries.patch} $out  --subst-var patchelf  <del> --subst-var dynamicLinker </del> <ins> --subst-var dynamicLinker  --subst-var libPath </ins> '') <ins> ) </ins> ]; doCheck = !stdenv.isAarch64 && !stdenv.isDarwin;

Related discussion:
text: Describe the bug As of rust nightly 2020-06-22, Rust nightly cannot find This issue is not present in Rust nightly 2020-06-21. To Reproduce Steps to reproduce the behavior: Expected behavior rustc works Additional context This also happens with rust nightly from Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(jade): nixpkgs: Maintainer information:
We are currently using in internally to set the elf interpreter. Looks like we need to extend this to also extend the RPATH to add zlib. If someone makes a PR, I will review it! Not sure when I would get to implement that myself.
Here is where we add :
I'm working on a patch for this. This is definitely the issue, just need to find the right way to extend the RPATH. I have something replacing it with a path containing zlib, but that overwrites the existing , which breaks it. I would like to verify what is setting there but hardcoding it should provide an early fix
Extending the RPATH seems not to have worked
I'm investigating patching the files in lib This issue may have been introduced by rust-lang/rust so it's likely the new zlib dependency shows up in the LLVM libraries
Code change:
let <del> inherit (lib) lists strings trivial; </del> <ins> inherit (lib) getLib lists strings trivial; </ins> inherit (magmaRelease) version hash supportedGpuTargets; # Per https://icl.utk.edu/magma/downloads, support for CUDA 12 wasn't added until 2.7.1.

Related discussion:
text: tests link to , however is not explicitly included in of . This issue is normally hidden, because (for example) links to and so it is brought along as a transitive dependency of . However, may not always be set to . For example, doesn't link to . As a consequence, applying the following overlay and attempting to build results in the following errors: does list in its , however actually refers to that only includes the wrapped compiler binaries. If my understanding is correct, is provided by instead. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
owner = "Rosettea"; repo = "Hilbish"; rev = "v${version}"; <del> sha256 = "sha256-n4+qUCbjqxLmGuCQ0QTscJ3me0UZUP/7ggvGp1pNkfg="; </del> <ins> sha256 = "sha256-fUGeQM+7FRGTRL3J4c2+c+NTwrM6d99F2ucKsou2kRk="; </ins> fetchSubmodules = true; };

Related discussion:
text: name: hilbish I guess? dunno how to use current version: 1.0.4 desired version: maintainers: Please tag this issue in your PR. I tried to update it myself: But that's not enough to get it to build and I have no experience with Golang stuff: Also: This is outdated. , and the releases have pre-compiled builds for both of them as well: !
Code change:
version = "111.0.1"; src = fetchurl { url = "mirror://mozilla/firefox/releases/${version}/source/firefox-${version}.source.tar.xz"; <del> sha512 = "e7d248b845cb524efc28818e0a0cad06ba5acac30219886191b702b61314388d10a1690c6d704b0a70d2bc2c4b1f04ed02350dcb9dce9c56503d2af3baefe4d3"; </del> <ins> sha512 = "b16c9399a19cb1de2d865a023d54fbe71c23a363ea4d36cd58f41f64f7ad04bc1b9d8a8448943417516e17337e0ee2afd370c29a72b51b0947161f4ffab6935f"; </ins> }; meta = {

Related discussion:
text: Steps to reproduce the behavior: firefox-unwrapped from master branch Please run and paste the result.
The hash listed in has apparently changed at 16:36 UTC today. The tarball was already available earlier than that, so the release apparently changed later that day. That would also line up with the hash you are seeing. ` In fact, we have the same hash as e.g. . Will investigate the change shortly, then update the hash.
Code change:
, hunspellDicts, spellcheckerLanguage ? null # E.g. "de_DE" # For a full list of available languages: # $ cat pkgs/development/libraries/hunspell/dictionaries.nix | grep "dictFileName =" | awk '{ print $3 }' <ins> , python3 , gnome , sqlcipher </ins> }: let

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:
"${config.boot.initrd.systemd.package}/lib/systemd/systemd-vconsole-setup" "${config.boot.initrd.systemd.package.kbd}/bin/setfont" "${config.boot.initrd.systemd.package.kbd}/bin/loadkeys" <del> "${config.boot.initrd.systemd.package.kbd.gzip}/bin/gzip" # keyboard layouts are compressed </del> <ins> "${config.boot.initrd.systemd.package.kbd.gzip}/bin/gzip" # Fonts and keyboard layouts are compressed ] ++ optionals (hasPrefix builtins.storeDir cfg.font) [ "${cfg.font}" ] ++ optionals (hasPrefix builtins.storeDir cfg.keyMap) [ "${cfg.keyMap}" </ins> ]; systemd.services.reload-systemd-vconsole-setup =

Related discussion:
text: With and , I still have to type my LUKS passphrase in qwerty. The logs say this: but not much else apparently. The vconsole is set up fine by the time I get a login prompt.
Dup of
Code change:
"${config.boot.initrd.systemd.package}/lib/systemd/systemd-vconsole-setup" "${config.boot.initrd.systemd.package.kbd}/bin/setfont" "${config.boot.initrd.systemd.package.kbd}/bin/loadkeys" <del> "${config.boot.initrd.systemd.package.kbd.gzip}/bin/gzip" # keyboard layouts are compressed </del> <ins> "${config.boot.initrd.systemd.package.kbd.gzip}/bin/gzip" # Fonts and keyboard layouts are compressed ] ++ optionals (hasPrefix builtins.storeDir cfg.font) [ "${cfg.font}" ] ++ optionals (hasPrefix builtins.storeDir cfg.keyMap) [ "${cfg.keyMap}" </ins> ]; systemd.services.reload-systemd-vconsole-setup =

Related discussion:
text: The option, which enables by default on high-resolution displays like my 4K laptop screen, is supposed to set the console font within the initrd before displaying the LUKS password prompt. However, with , this does not happen until stage 2, so the prompt is tiny. Enable , , and . The console font should be switched before the LUKS password prompt, not after.
Relevant code is probably that it sets . should then properly set everything up if it can find its files in :
Does it work when you do ?
No, it can’t, because points to a font file that’s not present in the initrd.
This works though. It’s a little jarring in that the font is changed about a second before the framebuffer resolution is changed, so it’s temporarily huge. Ideally those would happen simultaneously. But at least they both happen in time for the LUKS prompt.
Code change:
flycheck-rtags = fix-rtags super.flycheck-rtags; pdf-tools = super.pdf-tools.overrideAttrs (old: { <ins> # Temporary work around for: #   - https://github.com/vedang/pdf-tools/issues/102 #   - https://github.com/vedang/pdf-tools/issues/103 #   - https://github.com/vedang/pdf-tools/issues/109 CXXFLAGS = "-std=c++17"; </ins> nativeBuildInputs = [ pkgs.autoconf pkgs.automake

Related discussion:
text: The emacs package fails to build against the poppler version introduced in . See upstream issue vedang/pdf-tools. Steps to reproduce the behavior: should build Build log: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I'm seeing the same thing.
Same for me
Here's a work around:
Since above PR is merged and pdf-tools builds on current HEAD, I will close this.
Code change:
{ stdenv, lib, config, fetchFromGitHub, cmake, pkg-config , alsaSupport ? stdenv.isLinux, alsa-lib , pulseSupport ? config.pulseaudio or stdenv.isLinux, libpulseaudio <del> , jackSupport ? false, libjack2 </del> <ins> , jackSupport ? false, libjack2, soxr , pcapSupport ? false, libpcap </ins> }: stdenv.mkDerivation rec {

Related discussion:
text: Scream does not compile with jack support when it is explicitly enabled through an overlay. nixpkgs.overlays = [ (final: prev: { scream = { jackSupport = true; }; }) ]
Error message?
There is no error, it just skips compiling it. someone else ran it and i think they said that it skips compiling it with jack support because soxr is missing -- Checking for module 'jack' -- Found jack, version 1.9.19 -- Checking for module 'soxr' -- No package 'soxr' found
See . In the meantime, you can try: nixpkgs.overlays = [ (final: prev: { scream = ( { jackSupport = true; }).overrideAttrs (old: { buildInputs = old.buildInputs ++ [ ]; }); }) ]
Code change:
--interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"  --set-rpath $rpath $out/share/spotify/spotify <del> librarypath="${lib.makeLibraryPath deps}:$libdir" wrapProgramShell $out/share/spotify/spotify  ''${gappsWrapperArgs[@]}  ${lib.optionalString (deviceScaleFactor != null) '' --add-flags "--force-device-scale-factor=${toString deviceScaleFactor}"  ''}  --prefix LD_LIBRARY_PATH : "$librarypath"  --prefix PATH : "${gnome.zenity}/bin"  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--enable-features=UseOzonePlatform --ozone-platform=wayland}}" </del> # fix Icon line in the desktop file (#48062) sed -i "s:^Icon=.*:Icon=spotify-client:" "$out/share/spotify/spotify.desktop"

Related discussion:
text: When adding a local directory to spotify client, it always fails due to missing gsettings schema(s) and spotify crashes. This issue is the same as the one from 2021 Works as expected on arch based distros indicating that this an issue with nixpkgs Steps to reproduce the behavior: spotify Settings on Show Local Files ADD A SOURCE button Open a file chooser to select which directory to be . <!-- 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]:
I can't actually reproduce the issue, but I do see some inherent packaging issues that I attempted to address. Can you test the linked PR?
I also cannot reproduce the issue. However, I have never actually had local files appear after I have their directories (without crashing).
Yes your PR solves the issue!!! Thanks a lot for the fast reply :) I would really like to learn more about packaging programs for nixpkgs so I can contribute more myself. Do you have any recommendations on how to learn the different options for mkDerivation, the different phases, wrapping programs and libraries, etc.? I feel like the documentation is basically non-existend. If anything comes to mind (including workshops, etc.) feel free to just send me an email (this issue is probably the wrong place to discuss this)
Code change:
attrPath = "networkmanager"; versionPolicy = "odd-unstable"; }; <ins> tests = { inherit (nixosTests.networking) networkmanager; }; </ins> }; meta = with lib; {

Related discussion:
text: Describe the bug NetworkManager is a particularly important component and we don't have any tests for it that could block a channel advance. In particular, a change can happen on nixos-unstable leaving users without functioning networking, and while rollbacks are possible it isn't an excuse to allow that to reach production systems. NixOS doesn't produce either. Manual testing is also cumbersome if we want to make a new stable release. Upstream NetworkManager does have some integration testing but obviously not useful to us. I think to start, if we at least had a test that verifies the services start without issues would be great.
Agreed. While developing tests for the multipath TCP module I was surprised to see no networkmanager module. I had some difficulties with the nixos test infrastructure at first because the test infra will by default install a slirp interface () and it messed up the interface naming. Like I would clear but interfaces would still be named starting from instead of . Just thought I would mention it in case the brave soul writing the test is interested in multihoming. (but that's more a concern I have with the test infra).
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 .
Bleh.
I marked this as stale due to inactivity. &rarr;
consequences of our inactions