jiebi/CodeConvo huggingface dataset:
Change:
++ optional smbdSupport "--smbd=${samba}/bin/smbd"; doCheck = false; # tries to access /dev <ins> dontWrapGApps = true; </ins> <del> postFixup = '' </del> <ins> postFixup = '' </ins> # copy qemu-ga (guest agent) to separate output mkdir -p $ga/bin cp $out/bin/qemu-ga $ga/bin/ <ins> '' + optionalString gtkSupport '' # wrap GTK Binaries for f in $out/bin/qemu-system-*; do wrapGApp $f done </ins> ''; # Add a ‘qemu-kvm’ wrapper for compatibility/convenience.

Discussion:
Describe the bug On the branch 19.09, when i start a test interactively, the QEMU process segfaults. It works well when executed non interactively. To Reproduce In the kernel logs, i can see: Additional context The host kernel is and the nixpkgs commit of the NixOS deployment is (release 19.03). It seems to be working fine for a friend of mine, so it may be related to the execution environment.
I've been running VMs off unstable and 19.09 all week without issues. (host runs unstable) I believe it's because your host system is on 19.03 and the configuration you've built to run interactively is on 19.09. Though I wouldn't expect this to segfault, I've seen things like this happen before in a similar circumstance.
I upgraded to my host to 19.09 and i still run into this issue:( are you running VMs interactively?
Yes I have Perhaps hardware information could benefit this report, it could be an issue in QEMU.
So, I just tried to run the vm as root and it works well:/
if you're on a default 19.09, there should be a coredump, available via . Could you post the backtrace here - it might be helpful.
Thanks to the core dump, i have disable qemu () in the test vm and the process is no longer segfaulting! So, the culprit seems to be gtk. Here is the trace:
a segfault in sounds scary - what CPU is this running on?
Ok, it works well when I . It seems to be the same kind of issue than
cc
I guess it needs a wrapper. Pretty sure you don't run into ever if the executable is wrapped.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment.

on the . 3. Ask on the on .
It seems simply invokes , and wrapping gtk binaries is as simple as , so I opened this PR. I'd appreciate if you could test this, as I wasn't able to reproduce this issue locally.
I'm unfortunately no longer able to reproduce:(
Change:
xfce4-notifyd ]; <del> security.pam.services.xfce4-screensaver.unixAuth = true; </del> <ins> security.pam.services.xfce4-screensaver.unixAuth = cfg.enableScreensaver; </ins> }; }

Discussion:
introduced a locker by consequence if you enable the XFCE4 DE and the new locker replaces any other already defined without a trivial way to disable. Steps to reproduce the behavior: any other locker using something like 4 locker is used anyway A way to enable XFCE4 stuff but without the locker, it can be enabled by default but with a option to disable. (I can't screenshot on the lockscreen) This is the current commit of my config: <!-- 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.
Change:
, xfce , yyjson , zlib <del> , Apple80211 , AppKit , Cocoa , CoreDisplay , CoreVideo , CoreWLAN , DisplayServices , Foundation , IOBluetooth , MediaRemote , OpenCL , moltenvk </del> }: stdenv.mkDerivation (finalAttrs: { pname = "fastfetch"; <del> version = "2.3.4"; </del> <ins> version = "2.4.0"; </ins> src = fetchFromGitHub { owner = "fastfetch-cli"; repo = "fastfetch"; rev = finalAttrs.version; <del> hash = "sha256-jZeecymhjbXYE05zRF2dWHBS3hhRm1BmLB906YAlp+A="; </del> <ins> hash = "sha256-LHRbobgBXGjoLQXC+Gy03aNrTyjn1loVMbj0qv3HObQ="; </ins> }; nativeBuildInputs = [

Discussion:
Steps to reproduce the behavior: fastfetch log: related: <!-- 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]:
Yeah, this popped up after a staging change... I tried to look into a little bit before but not sure exactly what needs to change for it, yet.
Change:
[[package]] name = "time" <del> version = "0.3.34" </del> <ins> version = "0.3.36" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "c8248b6521bb14bc45b4067159b9b6ad792e2d6d754d6c41fb50e29fefe38749" </del> <ins> checksum = "5dfd88e563464686c916c7e46e623e520ddc6d79fa6641390f2e3fa86e83e885" </ins> dependencies = [ "deranged", "itoa",

Discussion:
Steps to reproduce the behavior: X 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]:
see
Change:
{ owner   = "poseidon"; repo    = "terraform-provider-ct"; <del> rev     = "v0.5.0"; version = "0.5.0"; sha256  = "1zqfaxlyhr9vpqj2qqpfyh1f1nfpynb7c5ris6mdmy9zin55ppni"; </del> <ins> rev     = "v0.6.1"; version = "0.6.1"; sha256  = "0hh3hvi8lwb0h8x9viz5p991w94gn7354nw95b51rdmir9qi2x89"; </ins> }; datadog = {

Discussion:
Where are the patches for "custom site approach PYTHONPATH" and NIXPYTHONSITES? I'd like to take a look. In particular, to compare with
Please feel free to reopen if there are concrete patches to look at.
Change:
buildPythonPackage rec { pname = "sphinx_rtd_theme"; <del> version = "0.2.5b2"; </del> <ins> version = "0.4.2"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "0grf16fi4g0p3dfh11b1624ic34iqkjhf5i1g6hvsh4nlm0ll00q"; </del> <ins> sha256 = "02f02a676d6baabb758a20c7a479d58648e0f64f13e07d1b388e9bb2afe86a09"; </ins> }; meta = with stdenv.lib; {

Discussion:
Ran . For some reason there are pylint tests running for ~8 minutes that eventually end up in a failure. <details<summaryPyLint test failures</summary</detailson pylint (indirectly?); running for ~10 minutes as part of package installation process.
This will need to be backported to 18.09 as the latest version released by Hydra is broken too
The tests still fails even after the above patch applied. <details<summaryHere is the log</summary</detailsHere is the patch I used: Edit: the original patch is working on the python-unstable branch so I guess it's OK
I pushed a fix to the branch: . The fix for is currently in the branch: .
Change:
postInstall = '' mkdir $data <del> cp -R $src/{public,templates} $data </del> <ins> cp -R $src/{public,templates,options} $data </ins> mkdir -p $out cp -R $src/options/locale $out/locale

Discussion:
Enabling the option during repository creation makes it fail with Internal Server Error. Additionally, the repository creation page doesn't list , and templates. Enable in NixOS configuration, open Gitea in browser, register a user, go to Create Repository page, enter repository name, check the checkbox, click , see it fails. system: host os: multi-user?: sandbox: version: channels(paul): channels(root): nixpkgs:
The reason for this is that the package doesn't include templates for README and other initial repository contents. It's easy to fix, I'll submit a PR.
There is a about the Debian package.
Change:
nativeBuildInputs = [ autoreconfHook ]; # tcmalloc uses libunwind in a way that works correctly only on non-ARM linux <del> buildInputs = stdenv.lib.optional (stdenv.isLinux && !(stdenv.isAarch64 || stdenv.isAarch32)) libunwind; </del> <ins> buildInputs = lib.optional (stdenv.isLinux && !(stdenv.isAarch64 || stdenv.isAarch32)) libunwind; </ins> # Disable general dynamic TLS on AArch to support dlopen()'ing the library: # https://bugzilla.redhat.com/show_bug.cgi?id=1483558 <del> configureFlags = stdenv.lib.optional (stdenv.isAarch32 || stdenv.isAarch64) </del> <ins> configureFlags = lib.optional (stdenv.isAarch32 || stdenv.isAarch64) </ins> "--disable-general-dynamic-tls"; <del> prePatch = stdenv.lib.optionalString stdenv.isDarwin '' </del> <ins> prePatch = lib.optionalString stdenv.isDarwin '' </ins> substituteInPlace Makefile.am --replace stdc++ c++ substituteInPlace Makefile.in --replace stdc++ c++ substituteInPlace libtool --replace stdc++ c++ ''; <del> NIX_CFLAGS_COMPILE = stdenv.lib.optionalString stdenv.isDarwin "-D_XOPEN_SOURCE -Wno-aligned-allocation-unavailable"; </del> <ins> NIX_CFLAGS_COMPILE = lib.optionalString stdenv.isDarwin "-D_XOPEN_SOURCE"; </ins> # some packages want to link to the static tcmalloc_minimal # to drop the runtime dependency on gperftools

Discussion:
Describe the bug A clear and concise description of what the bug is. I can't install mongodb in mac OS. I get the following errors when using nix shell and the following if I do a vanilla install To Reproduce try installing mongodb by and observe the error. Expected behavior Should be able to install mongodb on mac os. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. 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 Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(ashkanaleali): nixpkgs:
I'm not an expert but the error message seems to mean that the underlying issue is building gperftools. Also I don't have darwin so yeah.
Yes, this is a build failure of gperftools - assigning (maintainer)
I don't use macOS, gperftools or MongoDB so I don't know why I was tagged. I'm going to unsubscribe but feel free to tag me back in if I can somehow be of assistance.
It to be a recent regression. I don't have any macOS and don't know the platform well. If you add to the nix command, perhaps that will be helpful.
Can you/someone test?
I confirm that removing from fixes the build of on Darwin.
Change:
in { <del> options = { services.xserver.windowManager.qtile.enable = mkEnableOption "qtile"; </del> <ins> options.services.xserver.windowManager.qtile = { enable = mkEnableOption "qtile"; package = mkPackageOption pkgs "qtile" { }; </ins> }; config = mkIf cfg.enable { services.xserver.windowManager.session = [{ name = "qtile"; start = '' <del> ${pkgs.qtile}/bin/qtile start & </del> <ins> ${cfg.package}/bin/qtile start & </ins> waitPID=$! ''; }]; <del> environment.systemPackages = [ pkgs.qtile ]; </del> <ins> environment.systemPackages = [ # pkgs.qtile is currently a buildenv of qtile and its dependencies. # For userland commands, we want the underlying package so that # packages such as python don't bleed into userland and overwrite intended behavior. (cfg.package.unwrapped or cfg.package) ]; </ins> }; }

Discussion:
When enabling the Qtile window manager, globally defined Python environments cannot be used. Steps to reproduce the behavior: define a global Python environment in : Python environment: Qtile: defined Python environment is no longer available: I expect to be able to use globally defined Python environments regardless of the window manager in use, in this case, Qtile. This issue has been briefly discussed in NixOS .
Thanks a lot!
This exact issue still occurs for me; but only while being logged into Qtile.
Change:
{ enableGUI ? true, enablePDFtoPPM ? true, useT1Lib ? false , stdenv, fetchurl, zlib, libpng, freetype ? null, t1lib ? null <del> , cmake, qtbase ? null, makeWrapper </del> <ins> , cmake, qtbase ? null, qtsvg ? null, makeWrapper </ins> }: <del> assert enableGUI -> qtbase != null && freetype != null; </del> <ins> assert enableGUI -> qtbase != null && qtsvg != null && freetype != null; </ins> assert enablePDFtoPPM -> freetype != null; assert useT1Lib -> t1lib != null;

Discussion:
! system: host os: multi-user?: sandbox: version: nixpkgs:
I thought the problem might be due to imageformat plugin not being found, so I try: Result: ! There is some improvement, but still no icons. This seems to be same as on Linux. xpdf seems to use svg:
Change:
./no-etc-install.patch ./fix-qemu-ga.patch ./9p-ignore-noatime.patch <ins> (fetchpatch { name = "CVE-2019-3812.patch"; url = "https://git.qemu.org/?p=qemu.git;a=patch;h=b05b267840515730dbf6753495d5b7bd8b04ad1c"; sha256 = "03a5vc5wvirbyi5r8kb2r4m2w6f1zmh9bqsr2psh4pblwar0nf55"; }) </ins> ] ++ optional nixosTestRunner ./force-uid0-on-9p.patch ++ optional pulseSupport ./fix-hda-recording.patch ++ optionals stdenv.hostPlatform.isMusl [

Discussion:
, (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.
Change:
chmod +x $out/bin/transcrypt-depspathprefix ''; <ins> passthru.tests.version = testers.testVersion { package = transcrypt; command = "transcrypt --version"; version = "transcrypt ${version}"; }; </ins> meta = with lib; { description = "Transparently encrypt files within a Git repository"; longDescription = ''

Discussion:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR.
Change:
}; }; <ins> sdras.night-owl = buildVscodeMarketplaceExtension rec { mktplcRef = { name = "night-owl"; publisher = "sdras"; version = "2.0.1"; hash = "sha256-AqfcVV9GYZ+GLgusXfij9z4WzrU9cCHp3sdZb0i6HzE="; }; meta = { changelog = "https://github.com/sdras/night-owl-vscode-theme/blob/main/CHANGELOG.md#${ builtins.replaceStrings [ "." ] [ "" ] mktplcRef.version }"; description = "A Visual Studio Code theme named Light Owl for daytime usage"; longDescription = '' A VS Code theme for the night owls out there. Now introducing Light Owl theme for daytime usage. Decisions were based on meaningful contrast for reading comprehension and for optimal razzle dazzle. ''; downloadPage = "https://marketplace.visualstudio.com/items?itemName=sdras.night-owl"; homepage = "https://github.com/sdras/night-owl-vscode-theme"; license = lib.licenses.mit; maintainers = [ lib.maintainers.pladypus ]; }; }; </ins> seatonjiang.gitmoji-vscode = buildVscodeMarketplaceExtension { mktplcRef = { publisher = "seatonjiang";

Discussion:
Project description A VS Code theme for the night owls out there. Now introducing Light Owl theme for daytime usage. Decisions were based on meaningful contrast for reading comprehension and for optimal razzle dazzle. Metadata homepage URL: https://open- source URL: license: mit platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm creating this issue hoping to get some recommendations on where to look for information on how to package a vscode extension. I'm under the impression (correct me if I'm wrong) that a vscode extension should be a simpler project to package for my first shot at it. I've followed the contribution instructions for nixpkgs so I have the repo forked and ready to go. I'm just unfamiliar with what changes I actually need to make. Any assistance with this would be greatly appreciated.
Have a look in: Read the Edit: Build as:
Great, thanks. I'll look into those.
In case you can't solve your problem, we need to update docs. But then, I need to know what problem you are having.
I'm getting stuck on the value for that I'm suppose to use. Based on the other extensions I'm confident I'm not just using the commit hash but I'm not sure where the sha256 values are coming from. Do you have any additional information on this?
When you try to build it will generate the hash for you, so you copy and paste it. (What you have to do is just to erase the hash so it gets recomputed.)
Did it work for you? In case yes, consider upstreaming. (And closing this issue.)
I've kept the PR as a draft while I work out any issues with it and finish reading through the contribution docs. Is there any directions on how to correct the formatting? I thought I was following it while first making the
thanks for all your help with this process.
Change:
<ins> From 4e25ccee2f1eeed1dfdd9356b4fde511a48d9f01 Mon Sep 17 00:00:00 2001 From: Sarah Clark <seclark@nextquestion.net> Date: Sat, 24 Aug 2024 11:32:38 -0700 Subject: [PATCH] Update MANIFEST.in to remove .git references --- MANIFEST.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MANIFEST.in b/MANIFEST.in index 5ebcb7781..7340b1982 100644 --- a/MANIFEST.in +++ b/MANIFEST.in @@ -1,5 +1,5 @@ graft vendor/Heap-Layers -prune vendor/Heap-Layers/.git +# prune vendor/Heap-Layers/.git graft vendor/printf -prune vendor/printf/.git +# prune vendor/printf/.git exclude scalene/old/* -- </ins>

Discussion:
Steps to reproduce the behavior: python312Packages.scalene Per , this failure is intentional due to some behaviour changes in setuptools. I'm not completely familiar with the change or setuptools overall, but the gist seems to be that setuptools now "prefers installed dependencies over vendored ones", whatever that means in this case. fails on () Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
EDIT: Filed a PR to fix this in Scalene.
As soon as Emery has a fix on his end, we can bump the version number or apply the patch. Edit: Watch this PR
Updated in the original sources. We need Emery to cut a new release of Scalene as we're building from the published binary. (The scalene source build is complicated.)
FYI, I managed to make source builds work. That will make future bug responses quicker.
Change:
# Fix sandbox impurities. substituteInPlace Makefile.in --replace '/bin/pwd' 'pwd' substituteInPlace lib-src/Makefile.in --replace '/bin/pwd' 'pwd' <ins> # Reduce closure size by cleaning the environment of the emacs dumper substituteInPlace src/Makefile.in  --replace 'RUN_TEMACS = ./temacs' 'RUN_TEMACS = env -i ./temacs' </ins> ''; configureFlags = [

Discussion:
Describe the bug In NixOS 20.09, Emacs now has the output of gtk+ in its closure, which in turn causes it to pull in stuff like mesa-drivers (424 MiB): This caused the closure size of Emacs to increase from 339 MiB in NixOS 20.03 to 1324 MiB in 20.09. Metadata NixOS 20.09..
cc
This was reverted in
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
pname = "nanopb-generator-out"; inherit src version; <del> nativeBuildInputs = [ cmake protobuf python3 ]; </del> <ins> nativeBuildInputs = [ cmake protobuf ]; # don't let `find_program` find the bundled `protoc` script, so it will use the system `protoc` instead preConfigure = '' rm generator/protoc ''; </ins> cmakeFlags = [ "-Dnanopb_BUILD_RUNTIME=OFF" "-Dnanopb_BUILD_GENERATOR=ON" <del> "-Dnanopb_PYTHON_INSTDIR_OVERRIDE=$out/lib/python/site-packages" </del> <ins> "-Dnanopb_PYTHON_INSTDIR_OVERRIDE=${placeholder "out"}/${python3.sitePackages}" </ins> ]; <del> preConfigure = '' cmakeFlags+=" -Dnanopb_PYTHON_INSTDIR_OVERRIDE=$out/lib/python/site-packages" ''; </del> postInstall = '' rm -rf $out/include rm -rf $out/lib/cmake <del> ln -s $out/lib/python/site-packages $out/src </del> <ins> ln -s $out/${python3.sitePackages} $out/src </ins> ln -s ${pyproject_toml} $out/pyproject.toml ''; }

Discussion:
Steps to reproduce the behavior: nanopb, nanopbMalloc 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:
cre2 = callPackage ../development/libraries/cre2 { }; <del> criterion = callPackage ../development/libraries/criterion { }; </del> croaring = callPackage ../development/libraries/croaring { }; crocoddyl = callPackage ../development/libraries/crocoddyl { };

Discussion:
Package name: criterion Latest released version: 2.4.2 <!-- Search your package here: --- Current version on the unstable channel: 2.4.1 Current version on the stable/release channel: 2.4.1 <!-- 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. -- r-ryantm is failing to update the package because it now also depends on something called 'debugbreak'. Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The missing is here: (linked in the of criterion)
Change:
}) ]; <ins> postInstall = '' # Prevent patching this shell file, it only is used by sourcing it from /bin/sh. chmod -x $out/libexec/plasma-sourceenv.sh ''; </ins> extraNativeBuildInputs = [pkg-config spirv-tools]; extraBuildInputs = [ qtsvg

Discussion:
Plasma supports setting session environment variables by putting them into as bash scripts: Looking at , it seems like it's explicitly calling . However due to us running on all scripts in (since ), is now a binary file, and sourcing it with is now failing. This causes session variables not to run at all. Steps to reproduce the behavior: some script into a file in . Say a Plasma session. to observe the environment variable: . It should be exported. Please run and paste the result. (I'm using a flake) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Well this is fun. And we don't even have a way to skip individual targets in wrapQtAppsHook...
Is this something we would want to have? I think the other way we can close this is to patch so that it no longer runs the through , but since seems to dump all environment variables to pass into the Plasma session I'm not sure keeping the script wrapped is a good idea.
That's definitely easier, I'm just not entirely sure how correctly it'll work with weird shells... Though I guess /bin/sh is already assumed POSIX.
are you interested in looking into this further? I probably won't have the spoons to write up a patch for the next few days at least.
Sure, I will have a look should I have some spare time ^^ Le jeu. 6 juin 2024 à 17:58, K900 écrit :
Change:
glimpse = callPackage ../applications/graphics/glimpse { autoreconfHook = buildPackages.autoreconfHook269; <del> gegl = gegl_0_4; </del> lcms = lcms2; inherit (darwin.apple_sdk.frameworks) AppKit Cocoa; };

Discussion:
Describe the bug I get this: It can also be seen on hydra: successful build: (revision ) First unsuccessful build: (revision ) To Reproduce Expected behavior It should build. Notify maintainers Maintainer information:
Considering it's abandonware since there's a new version, not resolving it and just setting it as broken is perhaps best.
Or removing arch from meta.platforms. Though really, nothing should be using such ancient version these days.
See for alternative solution (dropping gegl 0.2 completely)