jiebi/CodeConvo huggingface dataset:
Change:
./remove-drm-support.patch # Make Heroic create Steam shortcuts (to non-steam games) with the correct path to heroic. ./fix-non-steam-shortcuts.patch <ins> # Fix reg add infinite loop # Submitted upstream: https://github.com/Heroic-Games-Launcher/HeroicGamesLauncher/pull/3210 ./fix-infinite-loop.patch </ins> ]; <ins> postPatch = '' # We are not packaging this as an Electron application bundle, so Electron # reports to the application that is is not "packaged", which causes Heroic # to take some incorrect codepaths meant for development environments. substituteInPlace src/**/*.ts --replace 'app.isPackaged' 'true' ''; </ins> configurePhase = '' runHook preConfigure

Discussion:
Heroic Launcher while trying to install a game from gog will download it, but won't install it. You can see downloaded installer inside your directory. After "installation", launcher will say on the game's details screen that It should install. ! You can't just use the gog installer like in a normal linux distribution: So you need to use steam-run to install it. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --heroic-launcher: 2.9.2 - unstable nixpkgs
This sounds exactly like a bug I encountered in a previous version of Heroic, but they have since fixed it, and I have not run into it on 2.9.2. Could you please attach the Heroic log file from right after trying to install the game? It's accessible via the sidebar Settings-Log.
<details</details
It looks like it successfully installs, going by that log. I seem to vaguely recall now having some issues with my GOG library in Heroic 2.9.2, and I eventually removed (with Heroic closed) and logged in to GOG through Heroic again, and it's been behaving since. You might try that, otherwise I don't see anything indicating this would be an issue specific to the Heroic package, so I think it would be appropriate to go to upstream's support channel, which is .
I will try moving to nixpkgs unstable and see if it was an issue of using stable and unstable in the same time. It should not, but maybe it is. Thank you for your help PS. I tried different game and the situation is still the same.
I found that heroic needs unzip to be installed to extract the gog linux installers. When I have somewhere in my installed packages (home or system), it just works. Probably it will have to be to the heroic wrapper.
Could you please try changing in your Nix config to the following and see if that fixes your problem?
By using: Everything started to work.
Change:
soundtouch = callPackage ../development/libraries/soundtouch {}; spandsp = callPackage ../development/libraries/spandsp {}; <ins> spandsp3 = callPackage ../development/libraries/spandsp/3.nix {}; </ins> spaceship-prompt = callPackage ../shells/zsh/spaceship-prompt {};

Discussion:
Describe the bug version 1.18.0 fails to build. To Reproduce Steps to reproduce the behavior: Expected behavior Build properly completes. Logs Full build log: Additional context This is blocking rebuilds. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(anna): nixpkgs: Maintainer information:
I'm experiencing this as well.
might be due to spansp upgrade in
Change:
).strip() == "${if pkgs.system == "aarch64-linux" then "amd64" else "arm64"}" ) <ins> with subtest("buildLayeredImage doesn't dereference /nix/store symlink layers"): docker.succeed( "docker load --input='${examples.layeredStoreSymlink}'", "docker run --rm ${examples.layeredStoreSymlink.imageName} bash -c 'test -L ${examples.layeredStoreSymlink.passthru.symlink}'", "docker rmi ${examples.layeredStoreSymlink.imageName}", ) </ins> ''; })

Discussion:
Describe the bug Please see for a more thorough investigation than this. ~I'm not sure I'd really classify this as a bug, but it is a least surprising behaviour on some docker storage backends, so I'd like to document this. I'm not sure whether docker really has any formal semantics with respect to the loading process.~ The TL;DR: Some s may be usable on some storage backends but not on others when symlinked paths are involved. To Reproduce Consider: This image fails to load on an ext4/overlayfs setup: But succeeds on a zfs-backed docker setup: I imagine this is because of the storage backend's behaviour wrt. earlier layers' files. Expected behavior Image loads the same on all backends. Additional context This was discovered because our docker images became unpullable on some hosts (overlay) but not others (zfs) after crate2nix started using symlinks for tested builds: might find this interesting. :smile_cat:
docker.. sounds like an upstream issue, no? What happens if you do the equivalent in a Dockerfile?
Yes, I tend to agree, both backends should behave the same, but I'm afraid "overlay" is the de facto standard, so the functioning version is probably the buggy one. I may report this upstream, but it's at least surprising that can produce unpullable images (never happened to me before!) :grinning: Uh, that would require a working memory on how to make Dockerfiles... Stand by. :stuckouttongue:
I can't seem to reproduce this with Dockerfiles. I suspect it does some logic to avoid having symlink breakage across layers, but I haven't checked the source. Maybe we should do the same.
Scratch the above, my assumptions were wrong. Here's what I now think is going on, seen only from the perspective of an overlayfs setup (forget about zfs, I've no idea what process the clone/snapshot mechanism uses to make this magically "work" and to what extent it actually "works") Given the snippet: We get an image which has a layer containing: This, I think, is the main culprit.

If we go to the prior commit (the commented nixpkgs revision) the problem does not exist, and the corresponding layer looks like this: Which looks much more correct and doesn't have more than one entry for with one being a symlink (correct) and the other (implicitly) a directory. In other words, I believe this is a bug and was introduced in specifically in and relates to how disparate entries are somehow created because of some wonky symlink traversal. :smile_cat: cc
Change:
./hplip-3.20.11-nixos-cups-ppd-search-path.patch ]; <del> prePatch = '' </del> <ins> postPatch = '' # https://github.com/NixOS/nixpkgs/issues/44230 substituteInPlace createPPD.sh  --replace ppdc "${cups}/bin/ppdc"  --replace "gzip -c" "gzip -cn" </ins> # HPLIP hardcodes absolute paths everywhere. Nuke from orbit. find . -type f -exec sed -i  -e s,/etc/hp,$out/etc/hp,g 

Discussion:
I expect all of these to not return "No such file or directory" and I expect the "bad interpreter" to be patched. I think it still "works", but compilation output should be clean such that when debugging something in the future there is not first a mess of other warnings to go through. Multiple issues: system: host os: multi-user?: sandbox: version: nixpkgs:
cc maintainers
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 . on the on .
The build currently complains that is missing: This program comes from ; I believe needs in .
I marked this as stale due to inactivity. &rarr;
As above, I think this is just a matter of adding the right .
I marked this as stale due to inactivity. &rarr;
Change:
irssi = callPackage ../applications/networking/irc/irssi { }; <ins> filebrowser = callPackage ../applications/networking/filebrowser { }; </ins> fish-irssi = callPackage ../applications/networking/irc/irssi/fish { }; kirc = callPackage ../applications/networking/irc/kirc { };

Discussion:
Project description Lightweight nextcloud/seafile/syncthing/ftp alternative to easily share files with mutiple users via HTTP Metadata homepage URL: source URL: license: Apache License platforms: any
I marked this as stale due to inactivity. &rarr;
need this too
I also have a work in progress for a module that wraps FileBrowser
If you submit a PR I can help review or test it
I've not quite sure how stacked PR's work on github as the previous one is still pending, but it would be great if you could test and leave feedback on this commit:
I've opened a new issue to discuss the options:
Change:
read -d "n" gradle_hash gradle_path < <(nix-prefetch-url --print-path $url) # Prefix and suffix for "native-platform" dependency. <del> gradle_native_prefix="gradle-$v/lib/native-native-" </del> <ins> gradle_native_prefix="gradle-$v/lib/native-platform-" </ins> gradle_native_suffix=".jar" <del> gradle_native=$(zipinfo -1 "$gradle_path" "$gradle_native_prefix*$gradle_native_suffix" | head -n1) </del> <ins> tmp=$(mktemp) zipinfo -1 "$gradle_path" "$gradle_native_prefix*$gradle_native_suffix" > $tmp gradle_native=$(cat $tmp | head -n1) </ins> gradle_native=${gradle_native#"$gradle_native_prefix"} gradle_native=${gradle_native%"$gradle_native_suffix"} <ins> # Supported architectures #grep -Pho "(linux|osx)-w+" $tmp | sort | uniq rm -f $tmp </ins> echo -e "{n  version = "$v";n  nativeVersion = "$gradle_native";n  sha256 = "$gradle_hash";n}" > $f echo "$v DONE"

Discussion:
Gradle 7.4 is out, see (I am one of the maintainers, this is a TODO.)
Change:
pyqtwebengine pyzmq requests <del> sip4 </del> <ins> sip </ins> ]; strictDeps = true;

Discussion:
Steps to reproduce the behavior: openshot-qt on nixos-unstable () Recently the default python was changed from 3.11 to 3.12, reverting to 3.11 works. Additionally on 3.11 sip can be upgraded from to (version 6) and it builds and runs, but using sip 6 with python 3.12 will result in a segfault. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The segfault with python 3.12 (and 6) is related to
Change:
, isPyPy }: <ins> let versionMajor = lib.versions.major protobuf.version; versionMinor = lib.versions.minor protobuf.version; versionPatch = lib.versions.patch protobuf.version; in </ins> buildPythonPackage { <del> inherit (protobuf) pname src version; </del> <ins> inherit (protobuf) pname src; # protobuf 3.21 coresponds with its python library 4.21 version = if lib.versionAtLeast protobuf.version "3.21" then "${toString (lib.toInt versionMajor + 1)}.${versionMinor}.${versionPatch}" else protobuf.version; </ins> disabled = isPyPy; <ins> sourceRoot = "source/python"; </ins> prePatch = '' <del> while [ ! -d python ]; do cd * done cd python </del> <ins> if [[ "$(<../version.json)" != *'"python": "'"$version"'"'* ]]; then echo "Python library version mismatch. Derivation version: $version, actual: $(<../version.json)" exit 1 fi </ins> ''; nativeBuildInputs = [ pyext ];

Discussion:
Steps to reproduce the behavior: nixpkgs electrum was recently updated 4.3.1 -4.3.2: previously built fine on nixpkgs 2022-09-28 () <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --<!-- attempting ti bisect, but on a slow machine, and it looks like there's miscellaneous failures over this duration so not sure it'll bisect cleanly: --
bisected to: good: bad: that's the staging-next merge though, so a lot of surface area. however, we appear to address a very similar build failure over in pkgs/development/python- by doing: i'm not sure how to test this same patch on electrum since it doesn't have any file.
oh just kidding, Electrum just places its in a different location. the patch below fixes the build when applied to master, and the application starts but i didn't test any functionality that i know touches protobuf. not sure how concerned i should be about overriding a pinned dep (i'm not a python dev):
Fix in
Change:
, openldap, lttngUst , babeltrace, gperf , cunit, snappy <del> , rocksdb </del> <ins> , rocksdb, makeWrapper </ins> # Optional Dependencies , yasm ? null, fcgi ? null, expat ? null

Discussion:
Enable and provision ceph and a mgr daemon. Ran on a modified nixos-unstable
Race you. :-)
Hehe, simple fix ;) and the steps to reproduce should include "enable dashboard module" because iirc it isn't enabled by default :)
solves the issue ^^
Oh, I see. I was converting an old cluster, and of course the dashboard was enabled there. Sorry! :-)
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 . on the on .
Iirc this was merged and resolved the 27th of March when merged my commit, so I'm closing this issue so that stalebot is happy
Change:
''; postInstall = '' <del> ( cd ${gnome3.defaultIconTheme}/share/icons/Adwaita for f in `find . | grep 'scanner.'` do local outFile="`echo "$out/share/icons/hicolor/$f" | sed  -e 's#/devices/#/apps/#g'  -e 's#scanner.#simple-scan.#g'`" mkdir -p "`realpath -m "$outFile/.."`" cp "$f" "$outFile" done ) </del> <ins> mkdir -p $out/share/icons mv $out/share/simple-scan/icons/* $out/share/icons/ </ins> ''; enableParallelBuilding = true;

Discussion:
Installed simple-scan. There are only place-holder icons in the toolbar. run look at toolbar with only place-holder icons System: NixOS: Nix version:nix-env (Nix) 1.11.4 Nixpkgs version: ""
What is your window manager?
I am using Enlightenment (e19).
do you mind confirming that this works?
Yes, it works. Thank you very much.
Change:
socketConfig.Accept = true; }; <del> services."sshd@" = service; </del> <ins> services.sshd-keygen = sshd-keygen-service; services."sshd@" = sshd-service; </ins> } else { <del> services.sshd = service; </del> <ins> services.sshd-keygen = sshd-keygen-service; services.sshd = sshd-service; </ins> };

Discussion:
If you have no hostkeys and try to connect to the openssh server, it will generate the keys but also send quite a bit of information to the client. I am not sure if this is an actual security issue but I wanted to bring it up just to make sure. hostkeys in /etc/ssh. with output will include System: (NixOS: , Ubuntu/Fedora: , ...) (Gorilla) Nix version: (run ) nix-env (Nix) 1.11.4 Nixpkgs version: (run ) ""
This is happening because of I'll create a PR with a fix tomorrow.
Yikes! Seems like way over-sharing to me.
Change:
<del> with import <nixpkgs> {}; </del> <ins> with import ../../.. {}; </ins> stdenv.mkDerivation { name = "generate-r-packages-shell"; buildCommand = "exit 1"; <ins> buildInputs = [ wget ]; </ins> nativeBuildInputs = [ (rWrapper.override { packages = with rPackages; [

Discussion:
Running and then Results in a lot of The solution is to include in the . I'll take care of this soon! Given above System: (Gorilla)
It would be great if you could send in a PR for this :) Thanks!
Already did :smile: It's the PR that references this issue (). I ran into some difficulty using and have been waiting for a response from someone more knowledgeable!
It might be a good idea to fix the missing wget dependency regardless of using ? EDIT: Submitted PR, also fixing another detail.
Change:
self.pytestrunner self.cryptography self.pyjwt <ins> self.setuptools-scm-git-archive </ins> ]; } );

Discussion:
"Source" link in search result on for Poetry package is pointing to poetry2nix source code instead of poetry. Steps to reproduce the behavior: on "Source" link in "poetry" package. This will point you to instead of When clicking on "Source" link in "poetry" package search results I want to get to "poetry" source code If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- 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:
This is really a bigger issue in how source code locations are extracted and it isn't unique to Poetry/Poetry2nix. The root cause is related to how is extracted: In this case is resolved to where Poetry2nix inherits descriptions from /. You can explicitly pass to which I just implemented in :
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
sha512 = "rvw3QTZc8lAxyVrqcSGVm5yP/IJ2UcB3U0graE3LCFoZ0Yn2x4EoVSqJKdB/T5M+FLcRPjz4TDacRf3OCfNUzw=="; }; }; <del> "workerd-1.20240610.1" = { name = "workerd"; packageName = "workerd"; version = "1.20240610.1"; src = fetchurl { url = "https://registry.npmjs.org/workerd/-/workerd-1.20240610.1.tgz"; sha512 = "Rtut5GrsODQMh6YU43b9WZ980Wd05Ov1/ds88pT/SoetmXFBvkBzdRfiHiATv+azmGX8KveE0i/Eqzk/yI01ug=="; }; }; </del> "workerpool-6.2.1" = { name = "workerpool"; packageName = "workerpool";

Discussion:
Steps to reproduce the behavior: nixos flake build, with nixpkgs/master, which worked yesterday and doesn't today fails on workerd fixed derivation that is pulled from npm may relate to based on commit histor <!-- 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. I do have a bunch of experimental flags enabled, they could impact something.. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
can you please review
Change:
{ config, lib, pkgs, ... }: <del> with lib; </del> let cfg = config.services.ttyd; <ins> inherit (lib) optionals types concatLists mapAttrsToList mkOption ; </ins> # Command line arguments for the ttyd daemon args = [ "--port" (toString cfg.port) ] ++ optionals (cfg.socket != null) [ "--interface" cfg.socket ]

Discussion:
After a recent upgrade ( followed by ) the browser-based terminal in my setup, served with ttyd, no longer accepts user input (i.e. where the user can type and enter commands through the browser). Normally you are greeted with a terminal login screen and can enter username/password and log in, but it is now no longer possible to type or submit either. After researching, there is a breaking change in ttyd version =1.7.4, where the terminal is now readonly by default, users must pass or to get an interactive terminal. Note that the release notes appear to incorrectly indicate a lower-case flag, upper-case is needed. Consulting both the listed and the nixpkgs , there is no currently no way to pass this option. I am unsure who if anyone is the maintainer of this service, although I see that maintains the ttyd package. I will attempt to fix and submit a PR.
Change:
{ pname <ins> , program </ins> , src , year , version , desktopName , longDescription , buildFHSUserEnv <del> , extraBuildInputs ? [] </del> <ins> , extraBuildInputs ? [ ] , jdk </ins> , stdenv , lib , dpkg

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 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: pdfstudio name: pdfstudioviewer <!-- 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: 2021.2.0 desired version: 2022.x.x <!-- 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.
Just purchased license for this product but can't use it as it's a 2022 license. Thanks for your help!
Change:
platforms = []; source = { remotes = ["https://rubygems.org"]; <del> sha256 = "1p6b3q411h2mw4dsvhjrp1hh66hha5cm69fqg85vn2lizz71n6xz"; </del> <ins> sha256 = "1g43ii497cwdqhfnaxfl500bq5yfc5hfv5df1lvf6wcjnd708ihd"; </ins> type = "gem"; }; <del> version = "1.13.3"; </del> <ins> version = "1.13.4"; </ins> }; nori = { groups = ["default"];

Discussion:
, CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc
Change:
ps.pecan ps.prettytable ps.webob <ins> ps.cherrypy </ins> ]); in

Discussion:
Enable and provision ceph and a mgr daemon. Ran on a modified nixos-unstable
Race you. :-)
Hehe, simple fix ;) and the steps to reproduce should include "enable dashboard module" because iirc it isn't enabled by default :)
solves the issue ^^
Oh, I see. I was converting an old cluster, and of course the dashboard was enabled there. Sorry! :-)
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 . on the on .
Iirc this was merged and resolved the 27th of March when merged my commit, so I'm closing this issue so that stalebot is happy