jiebi/CodeConvo huggingface dataset:
Change:
<del> { stdenv, fetchgit, makeQtWrapper, qtbase, qtquick1, qmltermwidget }: </del> <ins> { stdenv, fetchgit, makeQtWrapper, qtbase, qtquick1, qmltermwidget, qtquickcontrols, qtgraphicaleffects }: </ins> stdenv.mkDerivation rec { version = "1.0.0";

Discussion:
After running , cool-retro-term doesn't seem to work. When attempting to run, it outputs errors and hangs: This is on the current nixos-unstable channel:
Confirmed, already on 15.09 and persist on current master. /cc for latest changes and maintainer
That error message indicates it has missing dependencies; it is at least missing and . Unfortunately, Qt defers detection of dependencies until runtime whenever it can, instead of complaining during the build that these dependencies are missing.
Yeah, I've been looking into this a bit and and to buildInputs. The error message is now:
Although it's in the build inputs, it doesn't look like is being to the environment: returns no results.
isn't installing its QML files into the correct prefix. QML stuff should go into and QML2 stuff should go into , but puts everything into . Since the files are in the wrong location, they aren't picked up by .
Can we just tell that there's some QML stuff elsewhere? It's probably not the cleanest solution, but it would allow the package to work.
It would be better to fix . The Nix expression specifically patches the package to set the wrong QML path; I think if you simply remove that, it would work.
I tried removing the whole block: cool-retro-term gives the same error (), however.
Yeah, that's because there are more serious problems with how is packaged. You are the maintainer of , can you help us out here? I've taken a look at the package and I can't get it to respect Qt's QML import paths during installation.
Yeah, I will look into it.
Just got the same error:
I can confirm this issue on Ubuntu. Same problem here. installed using (v 1.1.1, rev126, stable) on Ubuntu 18.04.2 LTS
forgive me if I'm being dumb, but how does using on Ubuntu relate to NixPkgs?
Cool-retro-term simply "fails to run" due to this unresolved dependencies on many linux distributions. I just confirmed another one.

I don't understand, why this issue is closed now, that problem is not fixed - especially snaps shlould be able to handle QML dependencies somehow ,
In any case, I confirm this failure on nixpkgs master:
I don't see any changes in nixpkgs since this ticket was closed, but works on my nixos box.
QML packages rely on so they cannot be used without being installed to a profile.
Right, I apparently didn't know that at the time (or didn't recall it).
Try this....
I have the same problem. how to fix? user cool-retro-term QQmlApplicationEngine failed to load component Type TerminalContainer unavailable Type PreprocessedTerminal unavailable module "QMLTermWidget" is not installed Cannot load QML interface jre
Change:
description = "GNU Compiler Collection, version ${version} for AVR microcontrollers"; homepage = http://gcc.gnu.org; license = licenses.gpl3Plus; <del> platforms = platforms.linux; </del> <ins> platforms = with platforms; linux ++ darwin; </ins> maintainers = with maintainers; [ mguentner ]; }; }

Discussion:
A goal of mine for 18.09 is to get rid of some legacy cross compilation stuff. We can now use "crossSystem" to accomplish the same thing. [x] pkgs/development/compilers/arm-frc-linux-gnueabi-gcc/ [ ] pkgs/development/misc/avr/ [ ] pkgs/development/compiler/gcc-arm-embedded/ [ ] pkgs/development/compilers/mentor/ We want to make sure we have easy alternatives for the above. This might include providing aliases if they are needed. Also we might want to have Hydra build toolchains for AVR and ARM embedded.
I another entry: pkgs/development/compilers/mentor/. (Currently holds two old ARM toolchains.)
Change:
"cpu_freq" ]; <del> buildInputs = lib.optionals stdenv.isDarwin [ IOKit ]; </del> <ins> buildInputs = # workaround for https://github.com/NixOS/nixpkgs/issues/146760 lib.optionals (stdenv.isDarwin && stdenv.isx86_64) [ CoreFoundation ] ++ lib.optionals stdenv.isDarwin [ IOKit ]; </ins> pythonImportsCheck = [ "psutil" ];

Discussion:
For a while now, some routines have been segfaulting on darwin. This has become more problematic recently because newer versions of make a call to , which pretty robustly segfaults on darwin. Packages that use in their tests are failing as a result. e.g. 's own tests are of course disabled because they have proven to be so problematic. We've opened some upstream issues for these problems (, ), but I'm increasingly starting to feel these are Our Bugs. The next step is probably to do some proper debugging on these segfaults, but I personally lack the motivation to learn darwin's weird debugging ecosystem (give me gdb and ELF anyday), so instead I'm documenting my findings here. Steps to reproduce the behavior: on darwin (tested x86_64, macos 10.15) When I use a pip-installed version on the same machine it succeeds: Maintainer information:
I can’t reproduce on aarch64-darwin running macOS 12.0.1. I tried both the aarch64 and x86_64 builds of Python. (Not saying this isn’t a problem, but it may be that it’s dependent on the macOS version being run.)
~That is an interesting data point, because I'm quite certain that our uses a much newer SDK version.~ Hold on, I think we've miscommunicated, the pip method works for me too - I suppose listing it as the expected behaviour is unclear. Let me reword.
Does the first of my two snippets fail on your system?
Sorry, yeah. I also tested that first but only posted the second results. Here’s what I get with the first snippet.
I just tested the x86_64-darwin binaries on my aarch64-darwin system and got the crash.
Ok so it is still potentially SDK-version-related.
This sounds very similar to the problem in . I wonder if it's related.
I had a look at this when it was mentioned on matrix. From what I can tell the crash occurs as soon as psutil tries to interact with CoreFoundation types returned from querying the system. I did some printf style debugging by adding calls to , and all I could get was a crash. I suspect it's related to mixing and matching system CoreFoundation with swift-corefoundation built from source.

I haven't gotten to the bottom of the issue yet, but if psutil is explicitly linked with system CoreFoundation[1], then it seems to work. that forces the the linker to use system corefoundation. <details<summarycomparison</summaryWithout: With </details
how to resolve the issue?
Not sure if related I am getting this error
I also got same error on our CI (linux armd64) with . Is there a workaround for this?
Closing because of which is supposed to address this. And I can't reproduce on x86_64-darwin.
Change:
arrayfire = callPackage ../development/libraries/arrayfire {}; arrow-cpp = callPackage ../development/libraries/arrow-cpp ({ <ins> # Workaround until #91984 is in, this will need to be removed later. zstd = zstd.override { enableShared = false; }; </ins> } // stdenv.lib.optionalAttrs (stdenv.hostPlatform.isi686 && stdenv.cc.isGNU) { stdenv = overrideCC stdenv buildPackages.gcc6; # hidden symbol `__divmoddi4' });

Discussion:
Describe the bug arrow-cpp cannot be installed on Darwin To Reproduce Steps to reproduce the behavior: -env -i arrow-cpp Expected behavior Successful installation Additional context nix-build -A arrow-cpp from nixpkgs master fails with this error: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(lclaude): nixpkgs: Maintainer information:
Change:
+----------------------------------------------------------------------+ | Copyright (c) The PHP Group                                          | '') <ins> (pkgs.writeText "mysqlnd_fix_compression.patch" '' --- a/ext/mysqlnd/mysqlnd.h +++ b/ext/mysqlnd/mysqlnd.h @@ -48,7 +48,7 @@ #define MYSQLND_DBG_ENABLED 0 #endif -#if defined(MYSQLND_COMPRESSION_WANTED) && defined(HAVE_ZLIB) +#if defined(MYSQLND_COMPRESSION_WANTED) #define MYSQLND_COMPRESSION_ENABLED 1 #endif '') </ins> ]; postPhpize = lib.optionalString (lib.versionOlder php.version "7.4") '' substituteInPlace configure --replace '$OPENSSL_LIBDIR' '${openssl}/lib' 

Discussion:
After PR phpExtensions.mysqlnd not supported compression. Checked with
cc
Not supported gzip compression and OpenSSL signatures on phar package before update
Change:
githubId = 7121530; name = "Wolf Honoré"; }; <ins> wigust = { name = "Oleg Pykhalov"; email = "go.wigust@gmail.com"; github = "wigust"; githubId = 7709598; keys = [{ # primary: "C955 CC5D C048 7FB1 7966  40A9 199A F6A3 67E9 4ABB" fingerprint = "7238 7123 8EAC EB63 4548  5857 167F 8EA5 001A FA9C"; }]; }; </ins> wildsebastian = { name = "Sebastian Wild"; email = "sebastian@wild-siena.com";

Discussion:
Project description Tmuxifier allows you to easily create, edit, and load "layout" (template) files, which are simple shell scripts where you use the tmux command and helper commands provided by tmuxifier to manage Tmux sessions and windows. Cool demo video: <!-- Describe the project a little: --Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin,
Maybe the maintainers can add this? Maybe as a tmux option? ?
Change:
}; }) {}; <ins> luarocks = callPackage({ buildLuarocksPackage, fetchFromGitHub, fetchurl }: buildLuarocksPackage { pname = "luarocks"; version = "3.11.0-1"; knownRockspec = (fetchurl { url    = "mirror://luarocks/luarocks-3.11.0-1.rockspec"; sha256 = "0pi55445dskpw6nhrq52589h4v39fsf23c0kp8d4zg2qaf6y2n38"; }).outPath; src = fetchFromGitHub { owner = "luarocks"; repo = "luarocks"; rev = "v3.11.0"; hash = "sha256-mSwwBuLWoMT38iYaV/BTdDmmBz4heTRJzxBHC0Vrvc4="; }; meta = { homepage = "http://www.luarocks.org"; description = "A package manager for Lua modules."; maintainers = with lib.maintainers; [ mrcjkb teto ]; license.fullName = "MIT"; }; }) {}; </ins> luarocks-build-rust-mlua = callPackage({ buildLuarocksPackage, fetchFromGitHub, fetchurl }: buildLuarocksPackage { pname = "luarocks-build-rust-mlua";

Discussion:
luarocks exists that other luarocks packages can depend on. When trying to build a rockspec that depends on luarocks with , it fails. The entry in the generated luarocks config contains an entry for luarocks, but luarocks doesn't recognise it and tries to download the package instead. I have created a repository to reproduce it with: Run A workaround is to use to generate a expression for luarocks (), and to add that package to the 's instead of the package from nixpkgs. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for creating the test repo, it's helpful. I've looked at the generated LUAROCKSCONFIG and all looks good and I think luarocks just doesn't recognize the installed luarocks because of My first thought would have been to rename the current luarocks into a luarocksbootstrap and add a generated derivation, for which we could run the tests without the cyclic dependency luarocks -busted -luarocks. While this might be the best outcome longterm, I am looking into the quickfix which would be to generate the manifest for the current luarocks
Change:
<ins> # Thunderbolt 3 device manager { config, lib, pkgs, ...}: with lib; { options = { services.hardware.bolt = { enable = mkOption { type = types.bool; default = false; description = '' Whether to enable Bolt, a userspace daemon to enable security levels for Thunderbolt 3 on GNU/Linux. Bolt is used by GNOME 3 to handle Thunderbolt settings. ''; }; }; }; config = mkIf config.services.hardware.bolt.enable { environment.systemPackages = [ pkgs.bolt ]; services.udev.packages = [ pkgs.bolt ]; systemd.packages = [ pkgs.bolt ]; }; } </ins>

Discussion:
As described in , GNOME 3 needs the to handle authenticating Thunderbolt 3 devices. This is not yet packaged for NixOS. I've bolt myself but have thus far been unsuccessful. Start a Gnome 3 session Navigate to Settings → Devices → Thunderbolt Expected Results: A nice GUI as . Actual Results: An error message: ! (Note: The error message is slightly misleading. Thunderbolt 3 is supported and working on my laptop, albeit with authorization disabled, but without GNOME doesn't know that.) system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Can you share the errors you have encountered when packaging? Perhaps we can point you to solution.
Right now I'm hitting two roadblocks with bolt itself: the man pages fails somewhere inside asciidoc: I'm not sure how to get more information / further work on that. I disable manpage generation (), everything compiles and links just fine but then fails with:
Yeah, meson sometimes gives incredibly useless error messages. The problem is the build trying to install files in and , which it looks up through pkgconfig. Adding these fixes these: We'll also need to knock out as it tries to create a directory in . This fixed the build for me:
You can try to add flag to the asciidoc command in the meson file (I recommend setting to the local checkout of the project in question). As for the second error, Meson only calls when it fails to write to install destination, which means that some is probably wrong.
There ought to be a message Perhaps you can find it in build directory under if you run with .
Woohoo! ! Now I just have to: things up out how to get the systemd unit file linked out how to properly test a patch against this repo request!
We'll have to make module, something like this: Will probably need too.
Change:
#undef _PATH_SENDMAIL #define _PATH_SENDMAIL "${sendmailPath}" <ins> #undef _PATH_VI #define _PATH_VI "${vim}/bin/vim" </ins> #undef _PATH_DEFPATH #define _PATH_DEFPATH "/run/wrappers/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin:/usr/bin:/bin" __EOT__

Discussion:
When I run `sudo crontab -e", I get no crontab for root - using an empty one /bin/sh: /usr/bin/vi: No such file or directory crontab: "/usr/bin/vi" exited with status 127 Now I agree that I probably shouldn't do that (I should keep my crontab in ), but a better error message would probably be better. Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
I also have this issue. Current work around is but this needs to be fixed. See
Please feel free to close as this issue has been fixed.
Change:
if not EDITOR: f.write("editor 0n") if REBOOT_FOR_BITLOCKER: <del> f.write("reboot-for-bitlocker yesn"); </del> <ins> f.write("reboot-for-bitlocker yesn") </ins> f.write(f"console-mode {CONSOLE_MODE}n") f.flush() os.fsync(f.fileno())

Discussion:
Spent a fair bit debugging something. Came down to my DTB being out of sync. The lack of hash prefix should've warned me sooner. The issue is that the dtb is not copied with anything generation specific in the filename. The builder assumes the file is CA-addressed by parent store path, to avoid redundant copies. However, it also assumes it can make this path by taking basename of the specified file. This is file for initrd/kernel since they are second level in the derivation. However, this can't be assumed, and/or isn't true for the DTB. I would just send a PR but I can't think of a super easy/clean way to do this. The current approach (of assuming the depth of the file) is not great, IMO, but nicely avoids hashing the individual files, etc. Using a regex or chopping the prefix is not viable. The only idea I have -- use a regex to just capture the first instead of a b32 looking hash and hope that's good enough. I can do this depending on vibes. Steps to reproduce the behavior: two generation bug in older gen dtb from wherever it gets put (esp mount point or xbootldr), just to prove -install, which re-creates files for all generations, oldest first boot, notice old dtb, realize it lacks hash, realize this is fundamentally problematic. cc: A clear and concise description of what you expected to happen. 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
{ lib , mkDerivation , fetchFromGitHub , qmake <ins> , qttools </ins> , curl , ffmpeg , libmediainfo

Discussion:
MediaElch works correctly, except it cannot load StreamDetails. In About/Developer, it complains about not finding Steps to reproduce the behavior: or add it in MediaElch and scan some files to «Stream details» tab and try to «load from files» (3bis) You can also open About/Developer modal to see the message about the missing module. MediaElch should find libmediainfo and be able to use it to get info from media. ! NixOS 21.11 with Gnome/Wayland Thanks in advance !
As found by in it works perfectly with
Change:
, ceph , enableGlusterfs ? false , glusterfs <ins> , Carbon , AppKit </ins> }: with lib;

Discussion:
Found in It does build on and . Refs ZHF <!-- 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:
Is there a general fix for the error? I'm seeing this with (this issue was the only one in nixpkgs that matched that string, sorry if I'm completely off base, I just have no idea where to go on this)
Change:
}; patches = [ <ins> # CVE-2019-6133 - See: https://bugs.chromium.org/p/project-zero/issues/detail?id=1692 (fetchpatch { url = "https://gitlab.freedesktop.org/polkit/polkit/commit/6cc6aafee135ba44ea748250d7d29b562ca190e3.patch"; name = "CVE-2019-6133.patch"; sha256 = "0jjlbjzqcz96xh6w3nv3ss9jl0hhrcd7jg4aa5advf08ibaj29r1"; }) </ins> # CVE-2018-19788 - high UID fixup (fetchpatch { url = "https://gitlab.freedesktop.org/polkit/polkit/commit/5230646dc6876ef6e27f57926b1bad348f636147.patch";

Discussion:
, (nixos-18.09, nixos-unstable) Scanned versions: nixos-18.09: ; nixos-unstable: . May contain false positives.
Change:
<ins> { lib, stdenvNoCC, pijul }: lib.makeOverridable ( { url , hash ? "" , change ? null , state ? null , channel ? "main" , name ? "fetchpijul" , # TODO: Changes in pijul are unordered so there's many ways to end up with the same repository state. # This makes leaveDotPijul unfeasible to implement until pijul CLI implements # a way of reordering changes to sort them in a consistent and deterministic manner. # leaveDotPijul ? false }: if change != null && state != null then throw "Only one of 'change' or 'state' can be set" else stdenvNoCC.mkDerivation { inherit name; nativeBuildInputs = [ pijul ]; dontUnpack = true; dontConfigure = true; dontBuild = true; installPhase = '' runHook preInstall pijul clone  ''${change:+--change "$change"}  ''${state:+--state "$state"}  --channel "$channel"  "$url"  "$out" runHook postInstall ''; fixupPhase = '' runHook preFixup rm -rf "$out/.pijul" runHook postFixup ''; outputHashAlgo = if hash != "" then null else "sha256"; outputHashMode = "recursive"; outputHash = if hash != "" then hash else lib.fakeSha256; inherit url change state channel; } ) </ins>

Discussion:
It would be nice to add pijul () to the list of source controls that nix supports.
What are some motivating examples of software distributed via Pijul that you would like to see available through Nix/Nixpkgs?
Sort of a chicken and egg problem. My use case is for libraries. I want to start using pijul exclusively for source control for projects I control, therefore pulling source via say niv would require a fetchpijul to exist somewhere and nixpkgs seemed like the most likely place. It feels like a common theme that folks would be keen to use it over git if there were less friction and more integration options.
Concrete use case:
Is there a good high level outline on what needs to happen for the fetching process? I might be open to taking a stab at this, but just reading through the fetchgit source unassisted was a tad intimidating, I thought. Does there also need to be some work done in nix itself to support something like using Pijul for tracking what is included in a flake?
fetchFossil sounds like a better starting point…
Change:
<del> { stdenv, fetchdarcs, autoreconfHook, pkgconfig, gtk3 }: </del> <ins> { stdenv, fetchgit, autoreconfHook, pkgconfig, gtk3 }: </ins> stdenv.mkDerivation { name = "screen-message-0.23"; <del> src = fetchdarcs { url = "http://darcs.nomeata.de/screen-message.debian"; rev = "0.23-1"; </del> <ins> srcs = fetchgit { url = "git://git.nomeata.de/darcs-mirror-screen-message.debian.git"; rev = "refs/tags/0_23-1"; sha256 = "fddddd28703676b2908af71cca7225e6c7bdb15b2fdfd67679cac129028a431c"; </ins> }; buildInputs = [ autoreconfHook pkgconfig gtk3 ];

Discussion:
e.g. for screen-message () the following error occurs on hydra: A local build fetches the source just fine. cc
This seems to have fixed itself if it was down. The darcs repo no longer fails atleast on my side.
As I said, locally it’s perfectly fine, but from the hydra it doesn’t work. It’s a problem with hostname resolving of .
Hey sorry I misread. This seems reasonable until we figure out the hydra issue.
This is/was not a Hydra-issue, results in exactly the same.
Can someone reproduce this anywhere?
Change:
sha256 = "sha256-mV5b/J9wX9niiYtlmAUouaAm9mY2zTtDmex7FNWcezQ="; }; <del> nativeBuildInputs = with python3.pkgs; [ </del> <ins> nativeBuildInputs = with python.pkgs; [ </ins> poetry-core ]; <del> propagatedBuildInputs = with python3.pkgs; [ </del> <ins> propagatedBuildInputs = with python.pkgs; [ </ins> rich click requests

Discussion:
Steps to reproduce the behavior: Rich starts its pager Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(anselmschueler): nixpkgs:
This issue occurs because rich-cli isn't compatible with the newer rich version we have in nixpkgs. I'm not sure what the go is here as rich-cli hasn't been updated for a while (since Jun 21, 2022).
Ah, interesting. Maybe we should remove ?
I've done some more troubleshooting and the only thing I can find that doesn't seem to work is . If another issue comes up I'll mark it as broken, but I don't think this breaks the whole package as piping into another pager works fine.
I'd argue it is core functionality as from what I can gather it isn't just piping to your pager program but using a rich-specific pager.
Change:
tarsnapper = callPackage ../tools/backup/tarsnapper { }; <ins> tartube = callPackage ../applications/video/tartube { }; </ins> tayga = callPackage ../tools/networking/tayga { }; tcpcrypt = callPackage ../tools/security/tcpcrypt { };

Discussion:
Project description Tartube is a GUI front-end for youtube-dl, partly based on youtube-dl-gui and written in Python 3 / Gtk 3. Metadata homepage URL: source URL: license: gpl3 platforms: linux
I can't say I tested it extensively but here's my current derivation I have kicking around in a local overlay - Should at the very least be a starting point for someone.
Thank you so much. I'll keep this issue open until someone decides to close it.
You're welcome. And the issue should probably be kept open until someone contributes a derivation to nixpkgs proper (which I don't plan to for time being btw).