jiebi/CodeConvo huggingface dataset:
Change:
$(cat @clang@/nix-support/libc-cflags  @clang@/nix-support/libcxx-cxxflags)  ${NIX_CFLAGS_COMPILE} <del> initString="--init={"clang":{"extraArgs":[${extraArgs:1}]}}" </del> <ins> initString="--init={"clang":{"extraArgs":[${extraArgs:1}],"resourceDir":"@clang@/resource-root"}}" </ins> exec -a "$0" "@out@/bin/@wrapped@" "${initString}" "$@"

Discussion:
Describe the bug ccls complains about not found header files that I'd expect to be found. To Reproduce Steps to reproduce the behavior: a -file including or : : : <details<summaryFull output</summary</detailsccls shows the following error: Expected behavior successfully parses the file. Screenshots If applicable, add screenshots to help explain your problem. Additional context I'm afraid that I don't have the exact version numbers, but it worked correctly before I updated to 21.05. Edit: the used by ccls ( from the output above) does not exist on my system: 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 system: host os: multi-user?: sandbox: version: channels(florian): nixpkgs: Maintainer information:
I did some more investigation into this issue: The current version of ccls in the 21.05 tree reports the following version info and uses the following : In contrast this is what the ccls in the 20.09 tree reports: I'm absolutely not experienced with nix or this kind of issues, but this looks related to to me.
It looks like the detection of the resource dir at build time is incorrect. I tried to insert the correct path in the wrapper manually and that seems to work. The correct fix is should probably be in the configure phase instead.
Ah, this won't work, of course. Our ccls wrapper just needs to add an additional option, namely (with the right directory).
can this perhaps be back-ported to release-21.05?
Change:
nixFlakeBuild() { logVerbose "Building in flake mode." <del> if [[ -z "$buildHost" && -z "$targetHost" && "$action" != switch && "$action" != boot ]] </del> <ins> if [[ -z "$buildHost" && -z "$targetHost" && "$action" != switch && "$action" != boot && "$action" != test && "$action" != dry-activate ]] </ins> then runCmd nix "${flakeFlags[@]}" build "$@" readlink -f ./result

Discussion:
Running leaves a result symlink in the current directory. According to the man page, this is only supposed to happen with and . However, it looks like for the flake builder, it only . Steps to reproduce the behavior: a flake system configuration result symlink in current directory No result symlink is left around in the current directory. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I have some commits in but I am no maintainer.
Looks like intended behavior based on the source code: The reasoning seems to be that since does not touch the profiles unlike the other commands, it must create its own garbage-collector root.
Sorry! I looked at the 21.11 tree and there was no maintainer listed yet (should have looked in master) so I just picked the most recent committer. IMHO that is pretty annoying behavior, since I use frequently to test small changes to my configuration, pretty often also from different directories, so I end up having result symlinks all over my configuration which I then have to manually remove. Also, does it have to create its own garbage-collector root? If you mean, to prevent accidentally collecting the currently running system, I assumed that that's what /nix/var/nix/gcroots/current-system is for, to prevent exactly that.
If the GC quicks in before is set there is a race condition. I think would be enough to prevent that though, but I haven't looked at it in-depth.
Yeah, that's what I'd think as well. I haven't looked too closely yet either, but I would assume that for switch/boot, the temp link stays around until all the operations are done, which means there's always at least one gc root to the new configuration.
I've been using these patches since then and haven't encountered any issues, fwiw:
also leaves behind a symlink
Change:
unpackCmdHooks+=(_tryDebData) _tryDebData() { if ! [[ "$1" =~ .deb$ ]]; then return 1; fi <del> ar xf "$1" if ! [[ -e data.tar.xz ]]; then return 1; fi unpackFile data.tar.xz </del> <ins> ar xf $src if ! [[ -e data.tar.zst ]]; then return 1; fi unpackFile data.tar.zst </ins> } '';

Discussion:
Package name: bluej Latest released version: 5.2.0 <!-- Search your package here: --- Current version on the unstable channel: 5.1.0 Current version on the stable/release channel: 5.1.0 <!-- 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.
On it. I sadly still haven't found a good way of keeping up with releases, and I only actively use it myself from the end of september through to december.
PR at
Change:
runHook postInstall ''; <del> meta = with lib; { </del> <ins> meta = { </ins> description = "Gtk theme based on the Gruvbox colour pallete"; homepage = "https://www.pling.com/p/1681313/"; <del> license = licenses.gpl3Only; platforms = platforms.unix; maintainers = [ maintainers.math-42 ]; </del> <ins> license = lib.licenses.gpl3Only; platforms = lib.platforms.unix; maintainers = with lib.maintainers; [ luftmensch-luftmensch math-42 ]; </ins> }; }

Discussion:
Package name: gruvbox-gtk-theme Latest released version: unstable-2024-06-12 <!-- Search your package here: --- Current version on the unstable channel: unstable-2023-05-28 Current version on the stable/release channel: unstable-2023-05-28 <!-- 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]:
Change:
<del> #!/usr/bin/env ruby require 'json' system("elm-package install -y") depsSrc = JSON.parse(File.read("elm-stuff/exact-dependencies.json")) deps = Hash[ depsSrc.map { |pkg, ver| url = "https://github.com/#{pkg}/archive/#{ver}.tar.gz" sha256 = `nix-prefetch-url #{url}` [ pkg, { version: ver, sha256: sha256.strip } ] } ] File.open("package.nix", 'w') do |file| file.puts "{" for pkg, info in deps file.puts "  "#{pkg}" = {" file.puts "    version = "#{info[:version]}";" file.puts "    sha256 = "#{info[:sha256]}";" file.puts "  };" end file.puts "}" end </del>

Discussion:
Not sure whether this is darwin-specific. I cannot install next to , because both want link . It seems wrong for either of the packages to link shared libraries. I suspect this is because e.g. sets . I'd be happy to submit a patch to change this, but there seems to be a stack of scripts that's meant to generate this that's too deep for me. nix-env -iA nix-env -iA system: host os: multi-user?: sandbox: version: channels(rob): nixpkgs:
Usually we need a for these to work currently. Not sure if that is currently possible? You can also set meta.priority to a different number for each (default is 5). /cc
I think this must be darwin-specific; I have these packages happily coexisting alongside each other in on NixOS:
Yes, looks darwin-specific, via
Fixed in
Change:
looking-glass-obs = callPackage ./looking-glass-obs.nix { }; <ins> obs-backgroundremoval = callPackage ./obs-backgroundremoval { }; </ins> obs-gstreamer = callPackage ./obs-gstreamer.nix { }; obs-hyperion = qt6Packages.callPackage ./obs-hyperion/default.nix { };

Discussion:
Project description An OBS plugin for removing background in portrait images (video), making it easy to replace the background when screen recording. This package was removed in The build might be fixed as of if you don't mind giving it a try Metadata homepage URL: source URL: license: mit platforms: linux, darwin
The maintainer of the project has been active lately and there are a few new releases. Also see And
Change:
, html-tidy, libzip, zlib, pcre, pcre2, libxslt, aspell, openldap, cyrus_sasl , uwimap, pam, libiconv, enchant1, libXpm, gd, libwebp, libjpeg, libpng , freetype, libffi, freetds, postgresql, sqlite, net-snmp, unixODBC, libedit <del> , readline, rsync </del> <ins> , readline, rsync, fetchpatch </ins> }: let

Discussion:
, CVSSv3=8.8 (nixos-unstable) CVSSv3=5.4 (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.
talks about PHP 7.4.34 which does not exist. The mentioned mb_strtolower bug has been fixed in 7.4.4 and 7.3.16. So this is a false positive. Similar for bogus PHP versions mentioned in the CVE. PHP 7.4.34 does not exist again, and the changelogs don't mention anything similar for 7.3.16.
Change:
# Shared environment setup for graphical sessions. . /etc/profile <ins> if test -f ~/.profile; then source ~/.profile fi </ins> cd "$HOME" # Allow the user to execute commands at the beginning of the X session.

Discussion:
When coming from another distro, the environment of the sessions started by the X11 display managers aren't similar. This can lead to some custom programs not working, especially those that depend on environment variables e.g , , or whatever else these custom programs depend on. Steps to reproduce the behavior: an environment variable in e.g an application shortcut on the desktop with the command out and login the application short should contain ! nixOS has an undocumented and non-standard that is sources in  which took me days to find before understanding why wasn't being loaded. It would be great to not have to dig through code to find out a bout , but it would be even better to just use a standard file (namely ) instead of the aforementioned undocumented and non-standard . (who was the earliest author I could find for ) Please run and paste the result.
I think that's this old and long thread:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
sbcl ] ++ lib.optionals certifyBooks [ # To build community books, we need Perl and a couple of utilities: <del> which perl nettools makeWrapper </del> <ins> which perl hostname makeWrapper </ins> # Some of the books require one or more of these external tools: openssl.out glucose minisat abc-verifier libipasir z3 (python.withPackages (ps: [ ps.z3 ]))

Discussion:
The output from building the target on macOS: Note that if I hack the patch file associated with the derivation to use a extension, it builds fine.
The should be changed to a placeholder and then the placeholder should be replaced with
Change:
mkDerivation rec { pname = "calibre"; <del> version = "4.23.0"; </del> <ins> version = "5.9.0"; </ins> src = fetchurl { url = "https://download.calibre-ebook.com/${version}/${pname}-${version}.tar.xz"; <del> sha256 = "sha256-Ft5RRzzw4zb5RqVyUaHk9Pu6H4V/F9j8FKoTLn61lRg="; </del> <ins> sha256 = "a71196af15372054c4a25697534a2df1ef6dd732b9db07aaecaac7a86d9b3a0a"; </ins> }; patches = [

Discussion:
<!-- 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 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: calibre <!-- The current version can be found easily with the same process than 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: 4.23.0 desired version: 5.6 <!-- 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.
Change:
</para> </listitem> <listitem> <ins> <para> GNOME 3 has been upgraded to 3.34. Please take a look at their <link xlink:href="https://help.gnome.org/misc/release-notes/3.34">Release Notes</link> for details. </para> </listitem> <listitem> <para> If you enable the Pantheon Desktop Manager via <xref linkend="opt-services.xserver.desktopManager.pantheon.enable" />, we now default to also use <link xlink:href="https://blog.elementary.io/say-hello-to-the-new-greeter/"> Pantheon's newly designed greeter </link>. Contrary to NixOS's usual update policy, Pantheon will receive updates during the cycle of NixOS 20.03 when backwards compatible. </para> </listitem> <listitem> </ins> <para> By default zfs pools will now be trimmed on a weekly basis. Trimming is only done on supported devices (i.e. NVME or SSDs)

Discussion:
I have read the release notes of 20.03, here are the things i noticed: Linux kernel is updated to branch 5.4 by default (from 4.19). Users of Intel GPUs may prefer to explicitly set branch to 4.19 to avoid some regressions. Can you add a link to an open issue to see when it is fixed? At least link to "more information" e.g.: Not all entries are services. Maybe "Modules" would be more accurate? If we decide to change it, apply it to all NixOS releases. Some services are listed here, but they where just moved. For example: Best would be to update the tooling to exclude moved files and update it. The services.dnscrypt-proxy module has been removed as it used the deprecated version of dnscrypt-proxy. We've services.dnscrypt- to use the supported version. can't it be a drop-in replacement? it would be more user friendly if the new version would just be used with services.dnscrypt-proxy (i don't know the software, so it might makes sense) Update: This seems fine since the options have changed completely. It has option now. Maybe mention that the options have changed. Like "options are now organized using a settings option" or something like that to make it really clear fixed small typo myself (backported in )
I was hoping to do/address all these things :+1:
Change:
${mkKeepArgs cfg}  ${optionalString (cfg.prune.prefix != null) "--glob-archives ${escapeShellArg "${cfg.prune.prefix}*"}"}  $extraPruneArgs <ins> borg compact $extraArgs $extraCompactArgs </ins> ${cfg.postPrune} '');

Discussion:
The borg-backup-service has the ability to use to reclaim disk space. Since BorgBackup 1.2.0 (Released Feb 2022), this must be done manually using the command . If this command is not run regularily, the backup-space will fill. A fix would be to either implement a new service-option to regularly run on a different schedule or run on every prune. Update to Borg 1.2.0 and use the -options. Borg Backup disk space is reclaimed when a prune happens. Compatibility Notes states:
Any plans regarding this?
Sorry, just to be sure, how do you make sure that a is run after when a borgbackup job is setup in the ? I have already configured the option but not any or . I cannot see a "" option but only a option. Should I just include this last option like below and it should be ok?
Change:
# Hard code wine path in wrapper scripts generated by winegcc postFixup = '' <del> for exe in "$out"/bin/*.exe; do substituteInPlace "$exe"  --replace 'WINELOADER="wine"' 'WINELOADER="${wine}/bin/wine"' done </del> <ins> substituteInPlace "$out/bin/yabridge-host-32.exe"  --replace 'WINELOADER="wine"' 'WINELOADER="${wine}/bin/wine"' substituteInPlace "$out/bin/yabridge-host.exe"  --replace 'WINELOADER="wine"' 'WINELOADER="${wine}/bin/wine64"' </ins> ''; passthru.updateScript = nix-update-script { };

Discussion:
yabridge doesn't work with wine 9.5. I was wondering as this is a reoccurring thing with yabridge, shouldn't the wine version be pinned for the yabridge package? running vst plugins I tried overriding the wine version to 9.4 but I couldn't get it to build yabridge. So for now, I installed yabridge from the revision before wine 9.5. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can yabridge use the stable Wine package? It’s updated annually except for occasional bug fix releases. It’s currently Wine 9.0.
Didn't work for me:
From what I know, yabridge requires wine-staging but it's usually a few months behind. The project readme always had a downgrade section telling you to downgrade to a specific version. There's an open issue for it on the yabridge repo: ()
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Just created that should workaround this issue based on I think it would be best to keep it following the default staging release. What you're doing right now to pin wine uses an import for derivation, which isn't allowed in nixpkgs: It would be possible to maintain a separate derivation of wine just for yabridge, but I think it would be too costly for what it'd add - especially since we can't guarantee a version of wine that'll work with all VSTs.
I tried this as well, but most of my plugins were broken with wine 9.5 which will probably get fixed by yabridge upstream soon but I thought I should mention it. Oh, I didn't know about the implications importing older packages. Good to know. Yeah that would be too much unnecessary work.
Still broken on 9.6
is not merged yet. Even if it gets merged, I noticed some of my vsts breaking. I think it's better to pin version 9.4 for now.
Reopening since doesn't completely workaround regressions introduced with wine 9.5+
Fixed on wine 9.8 ()
Change:
<ins> { stdenvNoCC, lib, fetchurl, autoPatchelfHook, cups, unzip, }: stdenvNoCC.mkDerivation { pname = "cups-idprt-mt890"; version = "1.2.0"; src = fetchurl { name = "idprt_mt890_printer_linux_driver.zip"; url = "https://www.idprt.com/prt_v2/files/down_file/id/320/fid/778.html"; # NOTE: This is NOT an HTML page, but a ZIP file hash = "sha256-8yH+DSPRp4mjKOXw90TiGA4OzxJKHpBUMSLh3L2njw8="; }; buildInputs = [ cups ]; nativeBuildInputs = [ autoPatchelfHook unzip ]; installPhase = let arch = builtins.getAttr stdenvNoCC.hostPlatform.system { x86_64-linux = "x64"; x86-linux = "x86"; }; in '' runHook preInstall mkdir -p $out/share/cups/model $out/lib/cups/filter cp -r filter/${arch}/. $out/lib/cups/filter cp -r ppd/. $out/share/cups/model rm $out/share/cups/model/*.ppd~ chmod +x $out/lib/cups/filter/* runHook postInstall ''; meta = { description = "CUPS driver for the iDPRT MT890"; platforms = [ "x86_64-linux" "x86-linux" ]; license = lib.licenses.unfree; sourceProvenance = with lib.sourceTypes; [ binaryNativeCode ]; maintainers = with lib.maintainers; [ pandapip1 ]; }; } </ins>

Discussion:
Project description CUPS drivers for iDPRT label printers Metadata homepage URL: source URL: / license: proprietary platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
There is no need to create an issue for a software you are packaging. Create the package right away.
I wasn't planning on packaging the software. I opened this issue last week. About an hour ago I decided to bite the bullet and do it myself.
No problem.
Change:
buildPythonPackage rec { pname = "uvicorn"; <del> version = "0.24.0.post1"; </del> <ins> version = "0.27.1"; </ins> disabled = pythonOlder "3.8"; <del> format = "pyproject"; </del> <ins> pyproject = true; </ins> src = fetchFromGitHub { owner = "encode"; repo = pname; rev = "refs/tags/${version}"; <del> hash = "sha256-WMXOmQOTj/yPazPEAuteho4UH9enXcIa1mMDDl2eaIk="; </del> <ins> hash = "sha256-p0iPQE66RJfd811x6cnv7m3yvD/L9v7evBXlaIQSE0M="; </ins> }; outputs = [

Discussion:
Package name: uvicorn Latest released version: 0.27.1 Current version on the unstable channel: 0.24.0.post1 Current version on the stable/release channel: 0.23.2 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This should be closed, since the PR was merged.
Change:
slurp grim jq <ins> gnugrep </ins> ] }" '';

Discussion:
Steps to reproduce the behavior: add --wait to your command, for instance: no warning on nixos unstable <!-- 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]:
Change:
{ mkKdeDerivation, <ins> kcontacts, qtlocation, </ins> qtsvg, }: mkKdeDerivation { pname = "kongress"; <del> extraBuildInputs = [qtsvg]; </del> <ins> extraBuildInputs = [kcontacts qtsvg qtlocation]; </ins> }

Discussion:
there seem to be missing dependencies for kdePackages.kongress open the app i am at unstable channel. kongress version 24.08.0 the older version at libsForQt5.kongress still works Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
# Not packaged in nixpkgs # "com_github_googleapis_googleapis" # "com_github_googlecloudplatform_google_cloud_cpp" <del> "com_github_grpc_grpc" </del> <ins> # Issue with transitive dependencies after https://github.com/grpc/grpc/commit/f1d14f7f0b661bd200b7f269ef55dec870e7c108 # "com_github_grpc_grpc" </ins> # ERROR: /build/output/external/bazel_tools/tools/proto/BUILD:25:6: no such target '@com_google_protobuf//:cc_toolchain': # target 'cc_toolchain' not declared in package '' defined by /build/output/external/com_google_protobuf/BUILD.bazel # "com_google_protobuf"

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit Contents of : This issue was automatically generated by . that created this issue. Internal tags: -
Bisected to
Since then, updating both (currently v1.60 on ) and (to ) has not made any difference on this matter.
See
Change:
cp "$i"/* "$out/share/icons/hicolor/$(basename $i)/apps/" fi done mkdir $out/share/applications cp share/applnk/player/xdg/*.desktop $out/share/applications/ cp share/applnk/client/xdg-mime/*.desktop $out/share/applications/

Discussion:
Describe the bug Installing nomachine-client fails To Reproduce Steps to reproduce the behavior: to environment.systemPackages Expected behavior It should build the derivation Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
I tried overriding the hash (any tip on how to more properly do this would be appreciated), but still got build errors in my under environment.systemPackages result:
There's a PR to upgrade : I this to my and it seems to be working for me:
Yep, this is because NoMachine removes each old release as soon as they make a new one. To combat this, I'll add to the sources list when the update is done.
I was finding at the time that even overriding with the latest URL and hash from the nomachine website, that it was failing to download the whole blob. I could do it from my browser, but it seemed to abort/not download the full size via nixos
Oh, that's strange.. Thankfully, it seems to work just fine now :)