jiebi/CodeConvo huggingface dataset:
Change:
sha256 = "b4ca9a25a7d4f1ace4fffd1f3a2e64ef5208fe05f929f3edd5e27081ca7e67ce"; }; <del> patches = [ ./skip_bad_tests.patch ]; </del> buildInputs = [ libcap ]; <ins> checkInputs = [ pytestCheckHook ]; disabledTests = [ # Intel MPX support was removed in GCC 9.1 & Linux kernel 5.6 "test_mpx" # The Nix build sandbox has no_new_privs already enabled "test_no_new_privs" # The Nix build sandbox has seccomp already enabled "test_seccomp" # This will fail if prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_FORCE_DISABLE) # has been set system-wide, even outside the sandbox "test_speculation_ctrl" ]; </ins> meta = { description = "Python(ic) interface to the linux prctl syscall"; homepage = "https://github.com/seveas/python-prctl";

Discussion:
Describe the bug Recently, started failing to build due to a test failure in . To Reproduce Steps to reproduce the behavior: Expected behavior Should build succesfully Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(kira): nixpkgs: Maintainer information:
The failure seems to be caused by the recent upgrade:
Change:
patches = [ ./plugins-dir.patch <ins> # https://github.com/elementary/gala/pull/1259 # https://github.com/NixOS/nixpkgs/issues/139404 # Remove this patch when it is included in a new release # of gala OR when we no longer use mutter 3.38 for pantheon ./fix-session-crash-when-taking-screenshots.patch </ins> ]; postPatch = ''

Discussion:
When i try to take a screenshot of an area (STRG + PRINT), i hear the bell notification sound (that also comes when the disk is full) and nothing more happens (no screenshot). The third time i tried, the whole session crashed! I actually have a video of it: Steps to reproduce the behavior: screenshot with STRG + PRINT (not tested other methods) ??? crash actually taking screenshot that's the issue ;) Issue appeared after can you reproduce or should i get a log? system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
The issue is introduced in (though we are using Mutter 3.38). I will try to patch gala if possible, . Can confirm that the issue can be reproduced and by reverting the change the issue can be fixed. I will submit a PR in 48 hours.
Change:
wantedBy = [ "multi-user.target" ]; serviceConfig = { <del> # Runs login which needs to be run as root # login: Cannot possibly work without effective root User = "root"; </del> <ins> User = cfg.user; </ins> LoadCredential = lib.optionalString (cfg.passwordFile != null) "TTYD_PASSWORD_FILE:${cfg.passwordFile}"; }; script = if cfg.passwordFile != null then '' PASSWORD=$(cat "$CREDENTIALS_DIRECTORY/TTYD_PASSWORD_FILE") ${pkgs.ttyd}/bin/ttyd ${lib.escapeShellArgs args}  <del> --credential ${escapeShellArg cfg.username}:"$PASSWORD"  ${pkgs.shadow}/bin/login </del> <ins> --credential ${lib.escapeShellArg cfg.username}:"$PASSWORD"  ${cfg.entrypoint} </ins> '' else '' ${pkgs.ttyd}/bin/ttyd ${lib.escapeShellArgs args}  <del> ${pkgs.shadow}/bin/login </del> <ins> ${cfg.entrypoint} </ins> ''; }; };

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:
rm $out/jre/lib/jvmci/parentClassLoader.classpath ''; "11-darwin-amd64" = '' <del> echo "" </del> <ins> # BUG workaround http://mail.openjdk.java.net/pipermail/graal-dev/2017-December/005141.html substituteInPlace $out/conf/security/java.security  --replace file:/dev/random    file:/dev/./urandom  --replace NativePRNGBlocking  SHA1PRNG </ins> ''; }.${javaVersionPlatform};

Discussion:
Describe the bug When running I get the following error message: Looking at the executable the first line is: In fish does not return the name of the current executed file. It appear to work when running this using . Also as comparison look at the file generated via package manager: To Reproduce Steps to reproduce the behavior: Expected behavior should start the server Additional context So with . Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(yogsototh): nixpkgs: Maintainer information:
Hey this version is pretty outdated, could you try latest which is using graalvm binary?
Also the brew forumla you saw is outdated as well, the updated is
You are probably using the stable channel 20.09 channel, that should explain why you're still using the with JVM instead of GraalVM compiled binary. Switch to the unstable channel instead. I am not sure if it will work though since this package was never tested with macOS (and the fact that this package is broken in Hydra: ).
I just tested with latest master commit And if failed to build: I think the main bug is probably fixed. This is just another one :). This is late for me. I'll probably give it a look another day. Thanks for checking!
I think all GraalVM's packages build with Clojure are broken in macOS simply by the lack of people that has macOS systems to test/fix them. If you can fix this, a PR would be welcome :slightlysmilingface: .
Agreed If you have mac, using the homebrew official clojure-lsp formula should work as well: https://clojure-
Change:
serviceConfig = { User = "oauth2_proxy"; Restart = "always"; <del> ExecStart = "${cfg.package}/bin/oauth2_proxy ${mkCommandLine cfg}"; </del> <ins> ExecStart = "${cfg.package.bin}/bin/oauth2_proxy ${mkCommandLine cfg}"; </ins> }; };

Discussion:
NixOS services that depend on binaries are now broken (eg ) after This is because the attribute path for binaries has now changed. For example should now be .
I can do it tomorrow.
Change:
# tries to download many datasets for tests doCheck = false; <ins> pythonImportsCheck = [ "torchvision" ]; </ins> checkPhase = '' HOME=$TMPDIR py.test test --ignore=test/test_datasets_download.py '';

Discussion:
As per the title, the current CUDA and stdenv versions used to build are seemingly incompatible and can lead to build failures stating this (specifically - see below - but likely others as well). ~Likely introduced in ~ [of course it was the actual stdenv bump], but as it's a dynamic failure it's not a triviality to add an assert to to catch similar errors in future. with CUDA-enabled (e.g. in or override in ). Observe the build fails with the following output:
cc
This should be fixed when is merged.
Change:
unixODBC libxml2 libuuid <ins> zlib </ins> ] ++ (with xorg; [ libX11 libXext

Discussion:
Mathematica fails to start. .... System: NixOS: 17.03.1517. (Gorilla) Nix version: 1.11.11 Nixpkgs version: 17.03.1517. Sandboxing enabled: no
Similar issue in .
Change:
# various exporter templates patches = [ ./templates.patch <ins> # Use mistune 2.x (fetchpatch { name = "support-mistune-2.x.patch"; url = "https://github.com/jupyter/nbconvert/commit/e870d9a4a61432a65bee5466c5fa80c9ee28966e.patch"; hash = "sha256-kdOmE7BnkRy2lsNQ2OVrEXXZntJUPJ//b139kSsfKmI="; excludes = [ "pyproject.toml" ]; }) </ins> ]; postPatch = '' substituteAllInPlace ./nbconvert/exporters/templateexporter.py <ins> # Use mistune 2.x substituteInPlace setup.py  --replace "mistune>=0.8.1,<2" "mistune>=2.0.3,<3" </ins> ''; propagatedBuildInputs = [

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: python310Packages.nbconvert maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: -
Looks like this is due to was updated from 0.8.4 to 2.0.4, which doesn't satisfy 's requirement of .
Ah, seems it's going to be solved by .
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
rustPlatform.buildRustPackage rec { pname = "bingrep"; <del> version = "0.8.5"; </del> <ins> version = "0.9.0"; </ins> src = fetchFromGitHub { owner = "m4b"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-ayA3aEidZPa5GJgbbm5K3X2Xgd5Eb6TgUU80Gw/p07w="; </del> <ins> hash = "sha256-M3BYj1SKQKjEqP9cxaVlh7UeleDbcx6JN+UI6Ez+QJ8="; </ins> }; <del> cargoSha256 = "sha256-XcXllex7UEufV5URhH7aqln1tNxwaiAETO3fUKmHf7s="; </del> <ins> cargoHash = "sha256-botAoLNg/qTh+cjPXcjo/Ol2Vktj/c5130k5falEuLY="; </ins> meta = with lib; { description = "Greps through binaries from various OSs and architectures, and colors them";

Discussion:
, CVSSv3=7.5 (nixos-21.11, nixos-unstable) Bingrep v0.8.5 was discovered to contain a memory allocation failure which can cause a Denial of Service (DoS). Scanned versions: nixos-21.11: ; nixos-unstable: . Cc
Change:
VGA_SWITCHEROO         = yes; # Hybrid graphics support DRM_GMA600             = yes; DRM_GMA3600            = yes; <ins> DRM_VMWGFX_FBCON       = yes; </ins> # necessary for amdgpu polaris support DRM_AMD_POWERPLAY = whenBetween "4.5" "4.9" yes; # (experimental) amdgpu support for verde and newer chipsets

Discussion:
Installing NixOS on virtualbox with the minimal install CD. If I chose the default boot option, graphics would stop working around "NixOS Stage 1. Changing it to the (nomodeset), graphics started working. After installing NixOS and rebooting, graphics stopped working again at some point during systemd boot. I messed around with the graphics settings, changing the Graphics Controller from to fixed both issues. I was able to boot with the CD with the default GRUB boot option and I was able to boot using NixOS that was installed to the drive. Setup a VirtualBox Machine. I used 4096 MB or RAM. I set the CPU count to 4. You can double check that the problematic graphics controller is being used Download the NixOS minimal install CD, add it to the VirtualBox machine Start the machine Let it boot with the default boot option Graphics will stop working around NixOS Stage 1 You can workaround the issue in this case by selecting the option. Otherwise, you can change the Graphics Controller to and that should also fix it. My guess is that the default linux kernel doesn't support the VMSVGA graphics controller. The fix is probably just an extra config option in NixOS's default kernel config.
I booted with the graphics controller and the controller and captured the kernel log by adding to the kernel command line. I'm attaching both log files here. Even though the continued to graphics were completely hosed in the "NixOS State 1" part of boot, whch is near the beginning of the log file. The most noteworthy lines that could be indicating what is happening are these 2 lines in the logfile that don't appear in the logfile: As it's related to DRM seems like it's likely reporting an error related to why graphics completely stop working.
I'm getting the same issue with a Macbook pro.
Change:
<ins> # Env to update Gemfile.lock / gemset.nix with import <nixpkgs> {}; stdenv.mkDerivation { name = "env"; buildInputs = [ sqlite libpcap postgresql libxml2 libxslt pkgconfig bundix ]; } </ins>

Discussion:
The metasploit package no longer builds. I've updating it myself, but I haven't been very successful. If someone could point out my mistake I would gladly correct it and submit a PR.
Is this issue still relevant? , (pinging you because you are able to close this if necessary)
Looks relevant to me, as there was no commit to metasploit that updates or fixes it. Why do you think I isn't relevant anymore?
Current version: 3.3.1 Last stable version: 4.12 We definitely need a maintainer. is there a tag for ?
Change:
shellFor = { packages, withHoogle ? false, ... } @ args: let selected = packages self; <del> packageInputs = builtins.map (p: p.override { mkDerivation = haskellLib.extractBuildInputs p.compiler; }) selected; </del> <ins> packageInputs = builtins.map getHaskellBuildInputs selected; </ins> haskellInputs = builtins.filter (input: pkgs.lib.all (p: input.outPath != p.outPath) selected)

Discussion:
system: host os: multi-user?: sandbox: version: channels(luigy): nixpkgs:
cc
Change:
stdenv.mkDerivation rec { pname = "vlang"; <del> version = "weekly.2021.51"; </del> <ins> version = "weekly.2022.19"; </ins> src = fetchFromGitHub { owner = "vlang"; repo = "v"; rev = version; <del> sha256 = "1jvq3fxckl2jidiigkvclacjxbg5k38268mck7bl1ky1yspgfrnq"; </del> <ins> sha256 = "1bl91j3ip3i84jq3wg03sflllxv38sv4dc072r302rl2g9f4dbg6"; </ins> }; <ins> # Required for bootstrap. </ins> vc = fetchFromGitHub { owner = "vlang"; repo = "vc"; <del> rev = "c8ed2cd82b247e94c33217dba35c420cfc02fef3"; sha256 = "1acgx1qp480jmsv1xvqy1zf7iyy90mvg9x1m1b0zrwx09wz4y1cq"; </del> <ins> rev = "a298ad7069f6333ef8ab59a616654fc74e04c847"; sha256 = "168cgq6451hcgsxzyd8vq11g01642bs5kkwxqh6rz3rnc86ajic0"; </ins> }; <ins> # Required for vdoc. markdown = fetchFromGitHub { owner = "vlang"; repo = "markdown"; rev = "bbbd324a361e404ce0682fc00666df3a7877b398"; sha256 = "0cawzizr3rjz81blpvxvxrcvcdai1adj66885ss390444qq1fnv7"; }; # vcreate_test.v requires git, so we must disable it. patches = [ ./disable_vcreate_test.patch ]; </ins> propagatedBuildInputs = [ glfw freetype openssl ] ++ lib.optional stdenv.hostPlatform.isUnix upx;

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: <!-- 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: weekly.2021.51 desired version: weekly.2022.19 maintainers: Could some sort of auto-updater be in for this?
Current PR regarding this is
I saw that PR, but for some of my projects I need the latest version as it has some features I need. Thought I'd make an issue. What about auto-updating, btw?
I'm not sure, superficially I think it would be okay though. vlang is rather fast-moving, and that's both a good reason to auto-update, and a bad reason as there may be breaking changes regarding packaging it.
Yeah, good point. I still think that auto-updating is just a good idea so that issues like this don't have to be created.
Change:
sha256 = "0fb1mzs6sx76bl7f0z2xhc0jq6y1c55jrw1v3na8577is6g5ji0a"; }; <ins> patches = [ # Hardcode GSettings schema path to avoid crashes from missing schemas (substituteAll { src = ./hardcode-gsettings.patch; gds_gsettings_path = glib.getSchemaPath gsettings-desktop-schemas; }) ]; </ins> nativeBuildInputs = [ pkgconfig qmake ]; buildInputs = [ <ins> glib </ins> gtk3 qtbase qtx11extras

Discussion:
Following the last couple, I can now reproduce the issue again. I'm running NixOS off of , which is just with the previous too patches, that were still in staging`, applied. With that branch I get the following when I try to launch zoom: Edit: See
cc
I think this is a non-issue and was due to being an absolute pain in my ass. I'm testing and will update soon.
Alright, I can confirm that this is an issue, but seems to only affect zoom. cc.
What actions did you take? For me, on , it shows login page without an error (running ).
I'm running Zoom from recent master () and it doesn't crash. can you reproduce crash on that revision?
I later isolated the issue with jtojnar on the IRC. Try adding this clause to your configuration and see if you can repro the issue:
no crash for me, though I don't have an error "(process:): GLib-GIO-ERROR **: 21:32:14.611: No GSettings schemas are installed on the system" in a log. Maybe that's because I run gnome-shell, which has the ?
Maybe? I could/can consistently repro with the above
There must be some gsettings related code in the platform theme that needs to be patched/hardcoded.
Yeah, it wants the gnome hints which requires gsettings-desktop-schemas We can do a hardcode-gsettings patch like , to make it depend on gsettings-desktop-schemas since we can't wrap it. The issue doesn't appear in gnome because the global environment will have gsettings-desktop-schemas. You use sway right? Even there these should be available...
That is correct; I use sway configured with home-manager. Relevant configs:
This , should probably pull in , , and also.
cc. who, IIRC, worked on the sway Gtk wrapper.
Same issue for me under i3+dmenu
Change:
}; <del> config = { </del> <ins> config = let defaultFormatOptions = # -F needed to allow bare block device without partitions if (builtins.substring 0 3 config.fsType) == "ext" then "-F" # -q needed for non-interactive operations else if config.fsType == "jfs" then "-q" # (same here) else if config.fsType == "reiserfs" then "-q" else null; in { </ins> options = mkIf config.autoResize [ "x-nixos.autoresize" ]; <del> # -F needed to allow bare block device without partitions formatOptions = mkIf ((builtins.substring 0 3 config.fsType) == "ext") (mkDefault "-F"); </del> <ins> formatOptions = mkIf (defaultFormatOptions != null) (mkDefault defaultFormatOptions); </ins> }; };

Discussion:
The format script that is generated when specifying by default doesn't pass the mkfs options that are needed for non-interactive format for certain filesystems (, ). At least for , this prevents the format from completing, and leaves the system in unbootable state (it drops to emergency mode). This can be quite frustrating, and can take a while to figure out (especially if the system in question is something like nixops-deployed VPS without a root password). The option should "just work" (at least, for a fresh, unformatted volume), and not require the admin to discover the option of / and write it in . Add a blank volume/partition to the machine, and use it for a filesystem with : System: 17.03.1775. (Gorilla) Nix version: nix-env (Nix) 1.11.13 Nixpkgs version: "17.03.1775." Sandboxing enabled: no
addresses a similar issue (only related to non-partition devices, rather than "unfortunate" filesystems). I suppose I'll try to extend that solution and submit a pull request...
Change:
python3Packages.buildPythonApplication rec { pname = "ytcc"; version = "2.6.1"; <del> format = "pyproject"; </del> <ins> pyproject = true; </ins> src = fetchFromGitHub { owner = "woefe"; repo = "ytcc"; rev = "v${version}"; <del> sha256 = "sha256-pC2uoog+nev/Xa6UbXX4vX00VQQLHtZzbVkxrxO/Pg8="; </del> <ins> hash = "sha256-pC2uoog+nev/Xa6UbXX4vX00VQQLHtZzbVkxrxO/Pg8="; </ins> }; <del> nativeBuildInputs = [ gettext installShellFiles ]; </del> <ins> nativeBuildInputs = [ gettext installShellFiles ] ++ (with python3Packages; [ setuptools ]); </ins> propagatedBuildInputs = with python3Packages; [ yt-dlp

Discussion:
Steps to reproduce the behavior: ytcc directly from () that the build fails This could in fact be a upstream problem, as they haven't updated their build system since at least Oct 22, 2022. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
machine = { lib, ... }: { virtualisation = { # Since we're testing `limits.cpu`, we've gotta have a known number of <del> # cores to lay on </del> <ins> # cores to lean on </ins> cores = 2; # Ditto, for `limits.memory`

Discussion:
Please find stable urls for the lxd container tests these fail to download now and are causing test failures: cc
Thanks for pinging - I will fix it later today :-)
Change:
mergerfs-tools = callPackage ../tools/filesystems/mergerfs/tools.nix { }; <ins> meshoptimizer = callPackage ../development/libraries/meshoptimizer { }; </ins> mctc-lib = callPackage ../development/libraries/science/chemistry/mctc-lib { }; mstore = callPackage ../development/libraries/science/chemistry/mstore { };

Discussion:
Project description gltfpack is an application that can automatically optimise glTF files to reduce their complexity and file size. glTF is a open standard, created by Khronos, for describing 3D scenes. Metadata homepage URL: source URL: license: mit platforms: linux, darwin, windows
Thanks and
Change:
boinc = callPackage ../applications/science/misc/boinc { }; <ins> boinc-headless = callPackage ../applications/science/misc/boinc { headless = true; }; </ins> celestia = callPackage ../applications/science/astronomy/celestia { autoreconfHook = buildPackages.autoreconfHook269; inherit (gnome2) gtkglext;

Discussion:
Project description Currently there is a package for boinc, but it comes with a GUI manager. For a headless server it would be nice to have a package without graphical dependencies as an option. Unfortunately, I have no experience in creating packages myself, but I found these links that might be useful: General build instructions: Arch Package: Metadata homepage URL: source URL: license: gpl3, lgpl3 platforms: unix, linux, darwin
Change:
will no longer work and must be updated. </para> </listitem> <ins> <listitem> <para> The <literal>fluidsynth_1</literal> attribute has been removed, as this legacy version is no longer needed in nixpkgs. The actively maintained 2.x series is available as <literal>fluidsynth</literal> unchanged. </para> </listitem> </ins> </itemizedlist> </section> <section xml:id="sec-release-21.11-notable-changes">

Discussion:
no longer compiles with GLib 2.70: The failure looks patchable: We'd need to replace the use of in by an equivalent call to . However I'm not quite confident about the right place to call it, since we need to avoid calling it twice (which is UB according to the GLib documentation) and it looks like there are two different intialization routines that'd need to initialize the lock, and . Therefore I think should try to make an effort to finally get rid of this vulnerable version of fluidsynth (). Remaining uses: [x] , fixed in [x] (cc fixed in [x] (cc fixed in
Change:
sha256 = "1aqkhd6nwdn4xp5yz02zbymd4x8ij8fjw9ji8kh860n1a513k9ai"; prePatch = '' <del> substituteInPlace make/configure.in --replace '`sw_vers -productVersion`' '10.10' </del> <ins> substituteInPlace make/configure.in --replace '`sw_vers -productVersion`' "''${MACOSX_DEPLOYMENT_TARGET:-10.12}" </ins> substituteInPlace erts/configure.in --replace '-Wl,-no_weak_imports' "" ''; }

Discussion:
Describe the bug The current version of fails to build on macOS. From the error message it sounds like it believes the current macOS version is 10.10. The error message in question, from the configure phase: I suspect this was caused by which bumped our to 10.12. I have no idea why Erlang thinks the current macOS version is 10.10 (I'm running macOS 10.14). To Reproduce Steps to reproduce the behavior: macOS, run , or from a nixpkgs checkout run Expected behavior It should build. Additional context Add any other context about the problem here. Metadata system: host os: multi-user?: sandbox: version: channels(lily): nixpkgs: Maintainer information:
This is explicitly a problem with . I found the following in , , , and So at least it isn't a larger issue with Darwin. We should probably fix this to use . I'll work on a patch.