jiebi/CodeConvo huggingface dataset:
Code change:
''; }; <del> extraInitrd = mkOption { type = types.nullOr types.path; default = null; example = "/boot/extra_initramfs.gz"; description = '' The path to a second initramfs to be supplied to the kernel. This ramfs will not be copied to the store, so that it can contain secrets such as LUKS keyfiles or ssh keys. This implies that rolling back to a previous configuration won't rollback the state of this file. ''; }; </del> useOSProber = mkOption { default = false; type = types.bool;

Related discussion:
text: Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.
Code change:
<ins> { stdenv , lib , fetchFromGitHub }: stdenv.mkDerivation rec { pname = "nodenv"; version = "1.4.0"; src = fetchFromGitHub { owner = "nodenv"; repo = "nodenv"; rev = "v${version}"; sha256 = "0fgc23jd95rjll3dy5hnli8ksfc7rwscw53sdgss4yaharwlg8l2"; }; buildPhase = '' runHook preBuild bash src/configure make -C src runHook postBuild ''; installPhase = '' runHook preInstall mkdir -p $out cp -r libexec $out/ cp -r bin $out/ runHook postInstall ''; meta = with lib; { description = "Manage multiple NodeJS versions"; homepage = "https://github.com/nodenv/nodenv/"; changelog = "https://github.com/nodenv/nodenv/releases/tag/v${version}"; license = licenses.mit; maintainers = with maintainers; [ alexnortung ]; platforms = [ "x86_64-linux" ]; }; } </ins>

Related discussion:
text: Project description nodenv is one of version managers. I know you can manege with Nix itself, but majority of people in the frontend world assume everyone uses version managers which respect files like or , so you have to use them when you're working with them. Metadata homepage URL: source URL: license: MIT platforms: I'm not sure actually, but it's distributed as a homebrew formula
Hello, please check the merged pull request for notes on the package. The package works, but might need some changes or be extended to work better in the future.
Wow, thanks a lot for your help!
Code change:
<del> { lib, stdenv, fetchurl, cctools, fixDarwinDylibNames }: </del> <ins> { lib , stdenv , fetchurl , cctools , fixDarwinDylibNames , autoSignDarwinBinariesHook }: </ins> stdenv.mkDerivation rec { pname = "lp_solve"; version = "5.5.2.11";

Related discussion:
text: Steps to reproduce the behavior:
I don't have an M1 to test
Oh, it suffices to use . I'll open a pull request.
Code change:
substituteInPlace Makefile  --replace "/usr/local" $out <del> substituteInPlace bin/mix  --replace "/usr/bin/env elixir" "$out/bin/elixir" </del> ''; postFixup = ''

Related discussion:
text: I'm using Nix 1.9 on OS X 10.10.4 (Yosemite) with the package. It installs without issues, but when I try to use the tool I get this error: I'm using the unstable channel:
Hrm, I get (also Nix 1.9 and OS X 10.10.4) It seems to be an issue with the shebang in as seems to work just fine. I don't see anything obviously wrong with though... (PS hi long time no see :)
I just hit this issue too. Weirdly, just running from different shells would give different errors (I use fish normally, so it's always an early suspect around problems like this). I would get an error like got from , and an error like from . When I change my to this: Everything works, and in all shells the same way. Is this a valid fix? (By "works", I mean I get , but maybe that's a separate issue, or due to a lack of familiarity with Elixir/Erlang...)
Nice catch. Doing will generate a new app skeleton if everything is working as it should.
Turns out I just forgot to put the at the end of my fixed version, so no args were getting through :P Is what I mentioned above an acceptable fix? If so, I can submit a PR.
Code change:
<ins> { stdenv, fetchurl, makeWrapper, jre, callPackage }: let bare = callPackage ./bare.nix { inherit stdenv fetchurl makeWrapper jre; }; in stdenv.mkDerivation { pname = "scala"; inherit (bare) version; dontUnpack = true; installPhase = '' mkdir -p $out/bin ln -s ${bare}/bin/scalac $out/bin/scalac ln -s ${bare}/bin/scaladoc $out/bin/scaladoc ln -s ${bare}/bin/scala $out/bin/scala ln -s ${bare}/bin/common $out/bin/common ''; inherit (bare) meta; } </ins>

Related discussion:
text: Project description Scala 3 is more than a year old. It would be nice to have it packaged in nixpkgs as well. Maybe it is, but I couldn't find it under "scala-3" or respective versions. Metadata homepage URL: https://scala- source URL: license: Apache-2.0 License platforms: unix, linux, darwin, ...
is already packaged.
Indeed: the Scala 3 compiler started out under the codename 'dotty', and that's how it was packaged initially in nixpkgs. Now that dotty has become the 'official' scala 3 compiler (see also ), we should probably rename the package to as well? /cc
Feel free to update, rename and alias the old name :) Maybe should point at and can be
Code change:
<ins> diff --git a/src/sage_docbuild/ext/multidocs.py b/src/sage_docbuild/ext/multidocs.py index f91c7753ca..edeb81ff2e 100644 --- a/src/sage_docbuild/ext/multidocs.py +++ b/src/sage_docbuild/ext/multidocs.py @@ -284,6 +284,16 @@ def init_subdoc(app): if not app.config.multidoc_first_pass: app.connect('env-updated', fetch_citation) +            def fix_matplotlib_css_permissions(app: Sphinx, env): +                css_file = os.path.join(app.builder.outdir, '_static', 'plot_directive.css') +                try: +                    os.chmod(css_file, 0o644) +                except: +                    pass + +            # executed after matplotlib's _copy_css_file +            app.connect('build-finished', fix_matplotlib_css_permissions, priority=600) + # Monkey patch copy_static_files to make a symlink to "../" def link_static_files(): """ </ins>

Related discussion:
text: I have installed sage thorough the nix package manager and it is the only thing I use nix for so it is entirely possible I am doing something stupid and wrong. I have the latest from here build When I try to get to the index for all entries which is located on my computer, I get a page with very few entries (see the screenshot) below ! While I expect something more like Compare /nix/store/r77k14kq9iw92w32bd9sny7d98dbrq32-sagedoc-9.6/share/doc/sage/html/en/reference/genindex- and A full fledged index. I want to use to generate a docset which I can then search following the answer here I can build a docset after copying the reference directory to somewhere I have write access to. However when I try to search there are almost no results and I think this might be responsible. Please run and paste the result.
I'm not very involved in sage maintenance these days, I mostly contribute by reviewing and PRs every now and then. They are probably better qualified to help you :) Maybe we should drop me from the maintainers list, or at least change the order to reflect reality?
Sorry for the bother then! I was actually going by the information here which looked outdated but I didn't have any better idea.
Thanks for the report! Will take a look today.
Thanks a lot!
No bother :) Thanks for the pointer, I have updated the maintainer information there.
Code change:
# mupen64plus-input-gca is written in Rust, so we can't build it with # everything else. "-DNO_RUST=ON" <ins> "-DUSE_ANGRYLION=${lib.boolToString withAngrylionRdpPlus}" </ins> ]; qtWrapperArgs = lib.optionals stdenv.isLinux [

Related discussion:
text: There is a license violation in the package. The package contains the code for under the old MAME license which is non-commercial and incompatible with the GPL code in the rest of the program. I tried to notify upstream, but that didn't seem to go well...
Hello! It seems that upstream actually an option to disable in version of . , from my testing, gives me an error when I try to run it. You can find more info in this . So, i think merging the pull request linked to this issue is the best option right now.
Code change:
, at-spi2-core , cups , libxshmfence <ins> , obs-studio </ins> }: let

Related discussion:
text: I just filed a to update our version of CEF to fix a . The previous version was released on 2019-07-27— that's almost 2 years! For a piece of software that's functionally a web browser, we certainly shouldn't be using an out-of-date version: web browsers have a massive attack surface and it's very important to keep them updated at all times. I don't have the time to work on this right at the moment, but it shouldn't be too difficult. There's a containing metadata for every CEF release. All that should be necessary is to grab the latest stable version for the right platform. While we're at it, we could also consider building for i686 and AArch64. Tagging the maintainer
IDK how it works, but it sounds like a job for the bot ().
Code change:
, cairo , pango , npm-lockfile-fix <ins> , overrideSDK , darwin </ins> }: <del> buildNpmPackage rec { </del> <ins> let # fix for: https://github.com/NixOS/nixpkgs/issues/272156 buildNpmPackage' = buildNpmPackage.override { stdenv = if stdenv.isDarwin then overrideSDK stdenv "11.0" else stdenv; }; in buildNpmPackage' rec { </ins> pname = "bruno"; <del> version = "1.8.0"; </del> <ins> version = "1.10.0"; </ins> src = fetchFromGitHub { owner = "usebruno"; repo = "bruno"; rev = "v${version}"; <del> hash = "sha256-STWGZzFtU3UpctgNz3m96JyfSRzHy2ZZQPr8R+zpDgM="; </del> <ins> hash = "sha256-wxQaKewKIfN93Wvb7WmOSuflTgfk1XKvHAA1UIVyMqk="; </ins> postFetch = '' ${lib.getExe npm-lockfile-fix} $out/package-lock.json ''; }; <del> npmDepsHash = "sha256-0Uac4Q3EYiTkg6RFuwR+saXiVm7jISyZBjkN30uYnnE="; </del> <ins> npmDepsHash = "sha256-IXFFOegzJbDcQejqQsAg11jDnhSKi27Olm8m3qr7bqw="; </ins> npmFlags = [ "--legacy-peer-deps" ]; nativeBuildInputs = [

Related discussion:
text: 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
gnome.gnome-bluetooth_1_0 gnome.gnome-settings-daemon gnome.mutter <ins> gnome.zenity </ins> graphene gtk3 ibus

Related discussion:
text: When typing something here: <img src="https://user-" width=50%The desktop crashes and you have to re-login (well it's Chinese in the screenshot but I hope you get the idea) <img src="https://user-" width=50%Steps to reproduce the behavior: budgie menu something crash No crash. See above. I don't see this issue before the GNOME 44 update. Probably another issue but I haven't go deep yet. I am on right now, it's nixos-unstable with pull request picked.
Backtrace points to <details</detailsLooks like there are changes on that touches after 10.7.1, I am testing that right now.
I gave the latest HEAD (i.e. ) a try and cannot reproduce the issue so probably some of the commits fixes the issue. I wonder if this can be reproduce by others and if some fixes can be backported before 23.05
Ohhh goooooood and now I am reading , let me make some noise there Edit:
And now I am on , which has glib 2.74 ( has 2.76). This is going to be weird because with G_SLICE=always-malloc I also cannot reproduce the crash (budgie-desktop 10.7.1), so probably not related to the slice allocator. Edit: and it's vala 0.56.4 on (no crash) and 0.56.6 on (crash)
Okay I guess I can basically confirm it's caused by vala update because I am now on and cannnot reproduce the crash, wow it's first time I know valac can really cause issues :seenoevil: Bisect is too painful for my slow laptop :upsidedownface:
Could you try compiling and running this Vala code on the broken version to see if it also crashes? It should do the same thing as the crashing Budgie code, just without crashing your desktop. If this ends up being a Vala issue, we need a minimal reproduction program to send.
Code change:
gnome.gnome-bluetooth_1_0 gnome.gnome-settings-daemon gnome.mutter <ins> gnome.zenity </ins> graphene gtk3 ibus

Related discussion:
text: Build and run with (assuming you put it in a file called ):
I am now on and my desktop crashes, so the current range is :upsidedownface: I am away from keyboard for the next few hours because it's midnight here but feel free to drop questions :upsidedownface: I built the program with vala 0.56.5, it exits normally with
Well, crap. I was hoping that would crash. Maybe this version when you get back? It's closer to the code in Budgie: Of those commits, the only one that really looks suspicious to me is at a glance.
I am still here (for now) :laughing: but this runs normally for me as well (hmmm can we really guarantee "if I can trigger the desktop crash, then using same vala same laptop same setup we can trigger a crash with some different program"?)
Code change:
tor ]; <del> nativeCheckInputs = [ </del> <ins> nativeCheckInputs = with python3.pkgs; [ </ins> pytestCheckHook ];

Related discussion:
text: Steps to reproduce the behavior: onionshare <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The package distutils was remove in Python 3.12. Depends on upsteam. I raised a PR for the fix:
Code change:
# Required by Budgie Menu. gnome-menus <ins> # Required by Budgie Control Center. gnome.zenity </ins> # Provides `gsettings`. glib

Related discussion:
text: When typing something here: <img src="https://user-" width=50%The desktop crashes and you have to re-login (well it's Chinese in the screenshot but I hope you get the idea) <img src="https://user-" width=50%Steps to reproduce the behavior: budgie menu something crash No crash. See above. I don't see this issue before the GNOME 44 update. Probably another issue but I haven't go deep yet. I am on right now, it's nixos-unstable with pull request picked.
Backtrace points to <details</detailsLooks like there are changes on that touches after 10.7.1, I am testing that right now.
I gave the latest HEAD (i.e. ) a try and cannot reproduce the issue so probably some of the commits fixes the issue. I wonder if this can be reproduce by others and if some fixes can be backported before 23.05
Ohhh goooooood and now I am reading , let me make some noise there Edit:
And now I am on , which has glib 2.74 ( has 2.76). This is going to be weird because with G_SLICE=always-malloc I also cannot reproduce the crash (budgie-desktop 10.7.1), so probably not related to the slice allocator. Edit: and it's vala 0.56.4 on (no crash) and 0.56.6 on (crash)
Okay I guess I can basically confirm it's caused by vala update because I am now on and cannnot reproduce the crash, wow it's first time I know valac can really cause issues :seenoevil: Bisect is too painful for my slow laptop :upsidedownface:
Could you try compiling and running this Vala code on the broken version to see if it also crashes? It should do the same thing as the crashing Budgie code, just without crashing your desktop. If this ends up being a Vala issue, we need a minimal reproduction program to send.
Code change:
# Required by Budgie Menu. gnome-menus <ins> # Required by Budgie Control Center. gnome.zenity </ins> # Provides `gsettings`. glib

Related discussion:
text: Build and run with (assuming you put it in a file called ):
I am now on and my desktop crashes, so the current range is :upsidedownface: I am away from keyboard for the next few hours because it's midnight here but feel free to drop questions :upsidedownface: I built the program with vala 0.56.5, it exits normally with
Well, crap. I was hoping that would crash. Maybe this version when you get back? It's closer to the code in Budgie: Of those commits, the only one that really looks suspicious to me is at a glance.
I am still here (for now) :laughing: but this runs normally for me as well (hmmm can we really guarantee "if I can trigger the desktop crash, then using same vala same laptop same setup we can trigger a crash with some different program"?)
Code change:
bro = throw "'bro' has been renamed to/replaced by 'zeek'"; # Converted to throw 2023-09-10 inherit (libsForQt5.mauiPackages) buho; # added 2022-05-17 bukut = throw "bukut has been removed since it has been archived by upstream"; # Added 2023-05-24 <ins> butler = throw "butler was removed because it was broken and abandoned upstream"; # added 2024-06-18 </ins> # Shorter names; keep the longer name for back-compat. Added 2023-04-11 buildFHSUserEnv = buildFHSEnv; buildFHSUserEnvChroot = buildFHSEnvChroot;

Related discussion:
text: Package name: itch Latest released version: 26.1.3 Current version on the unstable channel: 26.1.3 Current version on the stable/release channel: 26.1.3 <!-- 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! --- The current version is broken since butler is marked broken 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The latest version on seems to be 26.1.3 which is used in the package.
There is 26.1.5 as a source code , but current package uses binaryBytecode
Code change:
let <del> common = { version, sha256 }: stdenv.mkDerivation (rec { </del> <ins> common = { version, sha256, extraPatches ? [ ] }: stdenv.mkDerivation (rec { </ins> inherit version; pname = "subversion";

Related discussion:
text: , CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
Code change:
owner = "iterative"; repo = "dvc-data"; rev = "refs/tags/${version}"; <del> hash = "sha256-8720nqWmi/1Be2ckuCvctfJbOSFCME27OOtA3qZMr7E="; </del> <ins> hash = "sha256-NBZbuOgM6m/8qhW+izXE4QRI3Ou28mF4nhESWF7Mmn0="; </ins> }; nativeBuildInputs = [ setuptools-scm ];

Related discussion:
text: Steps to reproduce the behavior: dvc actually it is hash problem. error from my nixos: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This happens not for the first time and probably not for the last time :cry:
Code change:
cpufetch = callPackage ../tools/misc/cpufetch { }; <del> crackmapexec = callPackage ../tools/security/crackmapexec { }; </del> crackxls = callPackage ../tools/security/crackxls { }; crd2pulumi = callPackage ../development/tools/crd2pulumi { };

Related discussion:
text: crackmapexec fails to run on the unstable branch. Full backtrace : Steps to reproduce the behavior: Should be marked as broken for python 3.12 and above due to not being maintained anymore, it should be recommended to use the maintained fork . If applicable, add screenshots to help explain your problem. I may PR a proper fix later if I find time to do so <!-- 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]:
I don't know if removal was the best choice for this tool but maybe has all the features that had so it's alright. It's just that I'm not aware if there are any bugs that are not in that are in but I understand why removal makes sense since later we'll move onto later version of Python such as 3.13 and further more
As is a fork, I guess that the feature set is comparable or even bigger in the meantime. is still available for 24.05 and could still be used after 24.11 with some magic.
I ran into this issue where didn't have it, it is just a minor issue so it's alright on my side, but not sure if there will be any more issues I'll ran into later :
Code change:
after = [ "network.target" "network-online.target" ]; environment = { <del> HOME = runtimeDir; </del> <ins> HOME = workDir; </ins> RUNNER_ROOT = stateDir; } // cfg.extraEnvironment;

Related discussion:
text: Working with large repositories on low-memory systems (such as aarch64-linux SBCs) can lead to out-of-storage scenarios with the github-runner service because the working directory is set to by default , which is sized to 25% of the system memory by default . Ideally there can be an option to use storage instead of memory for the working directory. I'm opening an issue first because I am not sure if there is a way to work around this already; can the argument in the service be overridden, or is there another way to change for this service with a systemd setting? If there isn't a straightforward solution I can open a PR to add this as an option. Maintainers:
I also experienced issues with no space left on . So far, however, increasing its size did the job. Nevertheless, I'd also appreciate the option to use another filesystem for the runtime directory. We won't be able to use systemd for that as it demands a -like filesystem for the runtime directory.
I guess standard installs avoid this by using the directory. Maybe we should just document how increase size instead of adding another option?
You may pass an arbitrary path to the options of the configuration script. Our module currently always uses the runtime directory systemd assigns to the service.
Yeah, in our case using the runtime directory that provides makes the most sense for dynamic user, again, with documentation on how to increase the size of the runtime directory. Currently our module doesn't support static users so isn't very useful... though I'm guessing our lack of support for static users is an oversight - see details here: