jiebi/CodeConvo huggingface dataset:
Change:
<ins> { lib, stdenv, fetchFromGitHub, rustPlatform, runCommand, xcodebuild, protobuf, boringssl }: let # boring-sys expects the static libraries in build/ instead of lib/ boringssl-wrapper = runCommand "boringssl-wrapper" { } '' mkdir $out cd $out ln -s ${boringssl.out}/lib build ln -s ${boringssl.dev}/include include ''; in rustPlatform.buildRustPackage rec { pname = "libsignal-ffi"; # must match the version used in mautrix-signal # see https://github.com/mautrix/signal/issues/401 version = "0.36.1"; src = fetchFromGitHub { owner = "signalapp"; repo = "libsignal"; rev = "v${version}"; hash = "sha256-UD4E2kI1ZNtFhwBGphTzF37NHqbSZjQGHbliOWAMYOE="; }; nativeBuildInputs = [ protobuf ] ++ lib.optionals stdenv.isDarwin [ xcodebuild ]; buildInputs = [ rustPlatform.bindgenHook ]; env.BORING_BSSL_PATH = "${boringssl-wrapper}"; # The Cargo.lock contains git dependencies cargoLock = { lockFile = ./Cargo.lock; outputHashes = { "boring-3.1.0" = "sha256-R6hh4K57mgV10nuVcMZETvxlQsMsmGapgCQ7pjuognk="; "curve25519-dalek-4.1.1" = "sha256-p9Vx0lAaYILypsI4/RVsHZLOqZKaa4Wvf7DanLA38pc="; }; }; cargoBuildFlags = [ "-p" "libsignal-ffi" ]; meta = with lib; { description = "A C ABI library which exposes Signal protocol logic"; homepage = "https://github.com/signalapp/libsignal"; license = licenses.agpl3Plus; maintainers = with maintainers; [ niklaskorz ]; }; } </ins>

Discussion:
crashes during startup with: Judging by this upstream issue which has the same stack trace, the crash is caused by using an incompatible version of the dependency with . specifies but currently in nixpkgs it's provided with as a dependency. It seems that an older version should be used to fix the crash. Steps to reproduce the behavior: might somehow be specific to my (judging by the stack trace, it might be related to e2ee), so here's mine: in parts in the provided mautrix-signal No crash Please run and paste the result.
Hello I've learned that the mautrix-signal python package is no longer going to receive any updates as they are currently rewriting it in Go, so a fix from them (to use newer mautrix) will not happen soon (I mean never, just that the go port wont have that particular issue) Until the go port is ready to be used, I've made the below override for myself, which effectively undoes commit for the mautrix dependency
Change:
stdenv.mkDerivation rec { pname = "cardinal"; <del> version = "22.12"; </del> <ins> version = "23.02"; </ins> src = fetchurl { url = <del> "https://github.com/DISTRHO/Cardinal/releases/download/${version}/cardinal+deps-${version}.tar.xz"; sha256 = "sha256-fyko5cWjBNNaw8qL9uyyRxW5MFXKmOsBoR5u05AWxWY="; </del> <ins> "https://github.com/DISTRHO/Cardinal/releases/download/${version}/cardinal-${version}+deps.tar.xz"; sha256 = "sha256-5vEWTkEXIMG/re7Ex+YKh+ETLDuc2nihTPpYSg5LdRo="; </ins> }; prePatch = ''

Discussion:
Package name: cardinal Latest released version: Current version on the unstable channel: v22.12 Current version on the stable/release channel: v22.10 <!-- 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 Note for maintainers: Please tag this issue in your PR.
Change:
<ins> { lib , rustPlatform , fetchFromGitHub , pkg-config , gtk3 , gtk-layer-shell , libpulseaudio }: rustPlatform.buildRustPackage { pname = "swayosd"; version = "unstable-2023-05-09"; src = fetchFromGitHub { owner = "ErikReider"; repo = "SwayOSD"; rev = "5c2176ae6a01a18fdc2b0f5d5f593737b5765914"; hash = "sha256-rh42J6LWgNPOWYLaIwocU1JtQnA5P1jocN3ywVOfYoc="; }; cargoHash = "sha256-ZcgrUcRQTcEYhw2mpJDuYDz3I/u/2Q+O60ajXYRMeow="; nativeBuildInputs = [ pkg-config ]; buildInputs = [ gtk3 gtk-layer-shell libpulseaudio ]; meta = with lib; { description = "A GTK based on screen display for keyboard shortcuts"; homepage = "https://github.com/ErikReider/SwayOSD"; license = licenses.gpl3Plus; maintainers = with maintainers; [ aleksana ]; platforms = platforms.linux; }; } </ins>

Discussion:
Project description A GTK based on screen display for keyboard shortcuts like caps-lock and volume Metadata homepage URL: source URL: license: gpl3-only platforms: linux
Change:
export QT_PLUGIN_PATH="$QT_PLUGIN_PATH${QT_PLUGIN_PATH:+:}${!outputLib}/lib/qt5/plugins" export QML_IMPORT_PATH="$QML_IMPORT_PATH${QML_IMPORT_PATH:+:}${!outputLib}/lib/qt5/imports" export QML2_IMPORT_PATH="$QML2_IMPORT_PATH${QML2_IMPORT_PATH:+:}${!outputLib}/lib/qt5/qml" <del> export RUNTIME_XDG_DATA_DIRS="$XDG_DATA_DIRS${XDG_DATA_DIRS:+:}${!outputBin}/share" export RUNTIME_XDG_CONFIG_DIRS="$XDG_CONFIG_DIRS${XDG_CONFIG_DIRS:+:}${!outputBin}/etc/xdg" </del> <ins> export RUNTIME_XDG_DATA_DIRS="$RUNTIME_XDG_DATA_DIRS${RUNTIME_XDG_DATA_DIRS:+:}${!outputBin}/share" export RUNTIME_XDG_CONFIG_DIRS="$RUNTIME_XDG_CONFIG_DIRS${RUNTIME_XDG_CONFIG_DIRS:+:}${!outputBin}/etc/xdg" </ins> } prePhases+=(_makeQtWrapperSetup)

Discussion:
On NixOS 17.03, the in the system configuration with Plasma 5 enabled, has and in its runtime closure, which causes unnecessary bloat. This is because has: then causes the directories of and to be to the wrapper script. (Automatically adding everything with a directory to the wrapper seems pretty drastic BTW.) System: NixOS Nix version: 1.12pre5073_1cf4801
KDE upstream is slightly careless about implicit runtime dependencies. I spent hours trying to figure out which runtime dependencies needed to be in . By the way, you have to guess at this because SDDM doesn't log error messages. Could we drop ? Probably. Can I answer that question for any of the other dependencies? Not a chance. So I nuked it from orbit. Guessing the correct setting would be a good project for a first-time contributor with a lot of free time. At the moment, I'm trying to get rid of entirely. This problem may go away as a happy accident, but that won't help this release. I'm open to other suggestions.
Change:
isQtStyle = cfg.platformTheme == "gtk2" && !(builtins.elem cfg.style ["adwaita" "adwaita-dark"]); isQt5ct = cfg.platformTheme == "qt5ct"; isLxqt = cfg.platformTheme == "lxqt"; <ins> isKde = cfg.platformTheme == "kde"; </ins> packages = if isQGnome then [ pkgs.qgnomeplatform pkgs.adwaita-qt ] else if isQtStyle then [ pkgs.libsForQt5.qtstyleplugins ] else if isQt5ct then [ pkgs.libsForQt5.qt5ct ] else if isLxqt then [ pkgs.lxqt.lxqt-qtplugin pkgs.lxqt.lxqt-config ] <ins> else if isKde then [ pkgs.libsForQt5.plasma-integration pkgs.libsForQt5.systemsettings ] </ins> else throw "`qt5.platformTheme` ${cfg.platformTheme} and `qt5.style` ${cfg.style} are not compatible."; in

Discussion:
The reason why I didn't open a PR, is described in . I'm aware of four platforms for Qt's themes right now: Using GTK themes through + ; Using GNOME themes through + ; Using Qt themes, with the non-KDE solution , which uses ; Using Plasma-targeted Qt themes, with as , as done natively in a plasma session, using the theme's colorscheme. Steps to reproduce the behavior:  and it does not provide ; equivalent to  providing ; , then add some Pasma-target themes like , then adjust envvars , set the theme in or with , you'll get the right theme with the proper color scheme. should provide (or ) as an option, it should add only the required packages to the system, and set the proper envvars. (or maybe rename it, since qt6 also uses the same variables and envvars) qbittorrent + breeze + + dark: ! qbittorrent + breeze + + dark: ! qbittorrent + (ignored my theme): ! qbittorrent + (also ignored my theme): ! I tried to discover what package that is being when evaluating provides this platform-theme, but I failed miserably. stated as maintainers of plasma-integration: stated as maintainer of qt5ct: qt5 module contributors: cc Please run and paste the result.
Not exactly your bug, but we should remove and integrate it with configs instead.
is another QT platform theme that can be integrated into config.
Change:
, ripgrep , Security , zip <ins> , fzf </ins> }: let

Discussion:
As of (),  ships with a binary called . However, the Nix package does not include in , which means that this executable fails if is not already in for some reason. Steps to reproduce the behavior: neither nor are installed/in in any other way (works) (produces ) (the UI will open, indicating that it works) In all honesty, this might be the expected behavior. is not the main functionality of , so it might be okay to ship it as is, where running will report that needs to be installed. However, I was caught off guard by this, and I expected that would work. and Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
stdenv.mkDerivation rec { pname = "system-config-printer"; <del> version = "1.5.12"; </del> <ins> version = "1.5.15"; </ins> src = fetchFromGitHub { owner = "openPrinting"; repo = pname; <del> rev = version; sha256 = "1a812jsd9pb02jbz9bq16qj5j6k2kw44g7s1xdqqkg7061rd7mwf"; </del> <ins> rev = "v${version}"; sha256 = "0a3v8fp1dfb5cwwpadc3f6mv608b5yrrqd8ddkmnrngizqwlswsc"; </ins> }; prePatch = ''

Discussion:
Describe the bug fails to build in the latest nixos-unstable (). This seems to be caused by a failing test: I'm running right now and will update this issue when it's done. To Reproduce Steps to reproduce the behavior: Additional context <details<summaryComplete build logs</summary</detailsNotify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --There aren't any maintainers listed :( Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
Seems to be a side effect of switching to Python 3.9 as default. Upstream has resolved this issue in v1.5.13 and newer.
I opened a PR that should fix this . As there are, as you mentioned, no maintainers, would you mind taking a look and leaving a review?
I still run into this issue on unstable?
Right now unstable is still at You can check to see when the channels were last updated.
Change:
configuration = { # Building documentation makes the test unnecessarily take a longer time: documentation.enable = lib.mkForce false; <ins> boot.kernel.sysctl."net.ipv4.ip_forward" = "1"; </ins> } // extra; };

Discussion:
not working in lxc containers. But sysctl command works fine and /proc/sys/ is writable. This nix option seems to finally take effect via . And the look like this: This looks fine, So I tried to manually run the command in , and it takes effect! But this looks even weirder. Through , I got: There is an unusual . It looks like this: Obviously, there is not is NixOS. So won't run at all. I looked it up on the internet and found out it's from distrobuilder: So maybe we should just patch it? Steps to reproduce the behavior: a privilege container with NixOS in it. something to and rebuild the system , and there is no effect should run and takes effect. <!-- 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]:
Are you able to you reproduce this with unstable? There are some improvements post 23.11 to the use of the lxc generator.
Yes, I'm already on latest unstable channel. The channel information in metadata tab is incorrect because I'm using flakes. There are many hard-coded FHS paths in distrobuilder. Such as this line, that causes this problem:
can you test this change?
It works fine for me. But I don’t know if there are any problems caused by other hard-coded paths in distrobuilder. And I don’t know whether using sysctl on an unprivileged container will cause the service to fail to start, and whether the startup failure will cause problems. But it seems that sets , so there should be no problem?
Thanks for testing! There shouldn't be, since we patch and wrap the distrobuilder lxc generator. I audited it again after updating the patch for this fix. You can always see the resulting file by building . The PR has tests which should cover unprivileged containers. I've just updated them to add a check verifying systemd-sysctl successfully started.
Change:
<del> { lib, stdenv, fetchurl }: </del> <ins> { lib, stdenv, fetchFromSourcehut }: </ins> stdenv.mkDerivation rec { pname = "scdoc"; version = "1.11.1"; <del> src = fetchurl { url = "https://git.sr.ht/~sircmpwn/scdoc/archive/${version}.tar.gz"; sha256 = "007pm3gspvya58cwb12wpnrm9dq5p28max2s0b2y9rq80nqgqag5"; </del> <ins> src = fetchFromSourcehut { owner = "~sircmpwn"; repo = pname; rev = version; sha256 = "1g37j847j3h4a4qbbfbr6vvsxpifj9v25jgv25nd71d1n0dxlhvk"; </ins> }; postPatch = ''

Discussion:
Describe the bug Sources from archives from fail to download with hash mismatches. To Reproduce Expected behavior The hash should match and the source should download. Additional context It sounds like , causing changes to all generated archives (to come in-line with GNU gzip). I've determined some packages which this affects (listed in "Maintainer information") by . I'm happy to have a go making a PR for all of these packages with the following process: archive from cache (by with subsituters) archive from both and confirm tar files are identical hash according to newly retrieved archive But if there's a better process, please let me know :) Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Sounds good
I think it is preferable to switch all affected derivations to fetchzip. This should prevent this from happening again, if the actual content of the tarball is the same. Even better, you could add a fetchFromSourceHut function which uses fetchzip under the hood, like fetchFromGitHub and fetchFromGitLab. This would encourage people not to use fetchurl to fetch procedurally generated tarballs from sourcehut.
From a quick look at the ticket, this is supposed to be a one-time change to make the hash the same as in other forges though
I think getting the new hashes with e.g. should be enough (fetches securely via HTTPS and we should be able to trust that the contents remain unchanged). +1, that seems like the best (long-term) solution. Edit: And IMO we should keep using archives (e.g. because it's consistent with the GitHub and GitLab fetchers) and should indeed be fine now:
the point is: with fetchzip, we don't have to trust this pinky promise (I mean, I'm sure that they intend to keep it, but it could break unwillingly). That's exactly why fetchzip exists in the first place. So on fixes keeping fetchurl.
oh, my bad, I didn't read your comment carefully enough :o I thought you've meant vs. (which didn't make much sense) but realized now that it was vs. . :+1: for that then :)
Hah, same. too then
is merged now so you could submit a PR to switch the affected attributes/packages to the new (s. ). I can also take care of it if you want.
Change:
<del> { name, stdenv, perl, makeWrapper, sqitchModule, databaseModule }: </del> <ins> { name, stdenv, perl, makeWrapper, sqitchModule, databaseModule, shortenPerlShebang }: </ins> stdenv.mkDerivation { name = "${name}-${sqitchModule.version}";

Discussion:
fails with the following error on macOS: To Reproduce Steps to reproduce the behavior: Expected behavior sqitch's version should be printed. Additional context seems to be the original sqitch main file, while exports in preparation of calling the original (perl) main file. However, still contains a shebang with all the library paths (each path is appended five times, but that's a different matter) as the environment variable, and when it's called, it fails with this error: Trial and error shows that limiting the shebang line to 512 character fixes the “exec format error” issue, and since there is no need to add all the paths (five times) to the shebang – since they are in the enviroment variable set by – they can be removed. This fixes the issue. Metadata Maintainer information:
Change:
dontWrapQtApps = true; configureFlags = [ <del> (lib.optionalString (!withHelp) "--without-help") </del> <ins> (lib.withFeature withHelp "help") </ins> "--with-boost=${getDev boost}" "--with-boost-libdir=${getLib boost}/lib" "--with-beanshell-jar=${bsh}"

Discussion:
Offline help is not available on Libreoffice, even though flag is enabled by default. Steps to reproduce the behavior: libreoffice to the system packages the offline help is missing the source for a potential setting, notice it's enabled by default and nothing ever touches it. for 3 months unsure if this is PEBKAC or not Have a toggle to build with help, or have a separate package that has the offline help. If applicable, add screenshots to help explain your problem. ! <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (note: raskin leads to an unrelated org, rename?) cc Please run and paste the result. PS: appears i got a double-zero issue id :D Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for the report, I think this should fix it (haven't tested the full build yet): .
I waited for CI to be green in to make sure it doesn't break the build. Could you please test it on your machine, and see if it indeed helped?
seems like it didn't use the cache so i'm waiting 2 hours for libreoffice to compile... fun!
Haha yes I know :) That's why I waited for CI to be green - to make sure that at least you won't encounter a build error after hours of building. Ideally, CI would have pushed to an online cache server such as . See also:
it works. it fucking works. !
Great, glad I could help :). Follow the PR at .
Change:
lomond = callPackage ../development/python-modules/lomond { }; <ins> loompy = callPackage ../development/python-modules/loompy { }; </ins> loopy = callPackage ../development/python-modules/loopy { }; looseversion = callPackage ../development/python-modules/looseversion { };

Discussion:
Project description Python implementation of the Loom file format Metadata homepage URL: source URL: license: bsd2 platforms: all Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
propagatedBuildInputs = [ pyqtwebengine proxy_tools <del> ] ++ lib.optionals (pythonOlder "3.7") [ importlib-resources ]; </del> <ins> six ] ++ lib.optionals (pythonOlder "3.7") [ importlib-resources ]; </ins> checkInputs = [ <ins> pygobject3 </ins> pytest <ins> qtpy </ins> xvfb-run ];

Discussion:
is failing to build due to test failures Steps to reproduce the behavior: Package should buikd Please run and paste the result.
Fails on Hydra:
Change:
lib, buildPythonPackage, fetchPypi, <ins> setuptools </ins> }: buildPythonPackage rec {

Discussion:
Project description Freeze (package) Python programs into stand-alone executables. Metadata homepage URL: source URL: license: gpl2 platforms: unix, linux, darwin
I would love to see it packaged too.
So, I did some digging on previous attempts at and found some abandoned PRs: packaged in itself but got abandoned due to complexity. was in partial effort of packaging by packaging one of its dependencies. also as a dependency for another package . Perhaps someone coming to this issue looking for the package can try it themselves using these attempts as a base.
I would also love to figure out how to build pyinstaller projects as a nix derivation
I believe you're looking for ? This issue is requesting to package itself and not packaging projects using .
Change:
codespell = callPackage ../development/tools/codespell { }; <ins> codux = callPackage ../applications/editors/codux { }; </ins> coolreader = libsForQt5.callPackage ../applications/misc/coolreader { }; corsair = with python3Packages; toPythonApplication corsair-scan;

Discussion:
Codux is a visual IDE for React that enables users to visually edit their projects and see changes reflected instantly in their code editor. It aims to streamline the development process and provide a more intuitive way to design and develop React applications. <!-- Describe the project a little: --Metadata homepage URL: source URL: (unfree) license: unfree platforms: windows, linux, osX
Change:
propagatedBuildInputs = [ google-cloud-sdk <ins> filetype </ins> jsonschema <ins> lib4sbom packageurl-python python-gnupg </ins> plotly beautifulsoup4 pyyaml

Discussion:
Project description A Python library to create SBOM files in several formats including SPDX and CycloneDX. Metadata homepage URL: source URL: license: Apache-2.0 platforms: Python
The expression for this can probably be automatically generated with a tool like nix-init, would you be down to maintain this package if I add it to nixpkgs?
Here's a generated expression, I can't get the test to pass though.
Change:
<del> diff --git a/bzip2recover.c b/bzip2recover.c index f9de049..252c1b7 100644 --- a/bzip2recover.c +++ b/bzip2recover.c @@ -457,6 +457,7 @@ Int32 main ( Int32 argc, Char** argv ) bsPutUChar ( bsWr, 0x50 ); bsPutUChar ( bsWr, 0x90 ); bsPutUInt32 ( bsWr, blockCRC ); bsClose ( bsWr ); +            outFile = NULL; } if (wrBlock >= rbCtr) break; wrBlock++; </del>

Discussion:
The package has a new maintainer and upstream:
Looks like they're up to 1.0.8 now, FWIW:
ping What's up with the "libtoolized" SUSE patch? AFAICT all it does it produce a useless file. Both the and the build without it; I rebuilt it with the stock 1.0.8 tarball and and shared-object Makefile and it seems to be fine. Hardly any packages even depend on anyway; mentions it in a weird , but that seems to break things rather than fix them, so I can't really test anything. The other one is which explicitly references for some insane reason (edit: I guess the is the wrong way round). It's dynamically loaded though, and I don't care enough to try and find what feature uses it. Perl also mentions . Not sure what to make of that.
The patch was useful before the recent maintenance pick-up upstream. I don't expect it will be useful anymore.
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 .
.
I marked this as stale due to inactivity. &rarr;
There exist bzip2 archives in the wild which cannot be extracted by the 1.0.6 that's in nixpkgs due to the fix for CVE-2019-. It takes some gymnastics to use them in derivations, etc. because bzip2 is such a core package. It would be nice to be able to upgrade to 1.0.8, which can handle these files, or move to the 1.1 series as default.
What mentions is still an issue. I mentioned that just now on the closed PR to merge 1.0.8:
Fixed by
Change:
nativeBuildInputs = [ go-bindata pkg-config perl ]; <del> vendorHash = "sha256-5b1WRq3JndkOkKBhMzGZnSyBDY5Lk0UGe/WGHQJp0CQ="; </del> <ins> vendorHash = "sha256-3Vf8BCrOwliXrH+gmZ4RJ1YBEbqL0Szx2prW3ie9CNg="; </ins> subPackages = [ "cmd/influxd" "cmd/telemetryd" ]; PKG_CONFIG_PATH = "${flux}/pkgconfig";

Discussion:
Steps to reproduce the behavior: There appears to be a cache miss, because starts to be compiled, but it fails. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
the maintainers to tag would be for v2 and and for v1 (all share the same build failure). v2 will be addressed via
Apologies. Thank you.