jiebi/CodeConvo huggingface dataset:
Code change:
stable = mkFlutter { pname = "flutter"; channel = "stable"; <del> version = "1.12.13+hotfix.8"; sha256Hash = "01ik4xckr3fp65sq4g0g6wy5b9i0r49l643xmbxa6z9k21sby46d"; </del> <ins> version = "1.12.13+hotfix.9"; sha256Hash = "1ql3zvmmk5zk47y30lajxaam04q6vr373dayq15jv4vpc0fzif1y"; </ins> patches = getPatches ./patches/stable; }; beta = mkFlutter { pname = "flutter-beta"; channel = "beta"; <del> version = "1.14.6"; sha256Hash = "1a79pr741zkr39p5gc3p9x59d70vm60hpz2crgc53ysglj4ycigy"; </del> <ins> version = "1.15.17"; sha256Hash = "0iil6y6y477dhjgzx54ab5m9nj0jg4xl8x4zzd9iwh8m756r7qsd"; </ins> patches = getPatches ./patches/beta; }; <del> dev = mkFlutter { </del> <ins> dev = mkFlutter rec { </ins> pname = "flutter-dev"; channel = "dev"; <del> version = "1.15.3"; sha256Hash = "06mawwqf7q7wdmzlyxlrlblhnnk4ckf3vp92lplippdh3d52r93i"; patches = getPatches ./patches/dev; </del> <ins> version = "1.17.0-dev.5.0"; filename = "flutter_linux_${version}-${channel}.tar.xz"; sha256Hash = "0ks2jf2bd42y2jsc91p33r57q7j3m94d8ihkmlxzwi53x1mwp0pk"; patches = getPatches ./patches/beta; </ins> }; }

Related discussion:
text: When trying to install , the build fails with: To reproduce, use the following and run it with : I think this happens because of the symlink of the , which seems to be resolved while running the build and in that case the symlink target does not exist. /cc btw: could you please also add support for the latest beta / dev / stable releases?
Hey it's fixed in the latest commit. Can you try it ?
Works fine, thank you very much for the fast fix!
Code change:
# Give key acme permissions chown '${data.user}:${data.group}' "${apath}/"{key,fullchain,full}.pem <del> chmod ${rights} "${apath}/"{key,fullchain,full}.pem </del> <ins> chmod ${fileMode} "${apath}/"{key,fullchain,full}.pem </ins> ''; serviceConfig = { Type = "oneshot";

Related discussion:
text: Describe the bug If I change and enable when the cert/key in question already exists the group access will not be granted after rebuilding and restarting the . This is because a condition in the post start script does so only when the key is newer than the existing one. To Reproduce Steps to reproduce the behavior: without group/allowKeysForGroup and start the service to reques the certificate group and allowKeysForGroup again and restart the service, the ownership/ode will not be updated Expected behavior The group and chmod setting should be set on existing certificates as well as new ones. Metadata Please run and paste the result. Maintainer information:
Additionally, shouldn't chmod 0640 suffice on the files?
cc as potentially interested individuals
Code change:
python3Packages.buildPythonApplication rec { pname = "keepmenu"; <del> version = "1.2.2"; </del> <ins> version = "1.3.1"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "SeVNtONH1bn2hb2pBOVM3Oafrb+jARgfvRe7vUu6Gto="; </del> <ins> hash = "sha256-AGuJY7IirzIjcu/nY9CzeOqU1liwcRijYLi8hGN/pRg="; </ins> }; preConfigure = ''

Related discussion:
text: Package name: keepmenu Latest released version: 1.3.1 Current version on the unstable channel: 1.2.2 Current version on the stable/release channel: 1.2.2 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Code change:
oldInterpreterLine=$(head -1 "$f" | tail -c+3) read -r oldPath arg0 args <<< "$oldInterpreterLine" <ins> if [ -z "$pathName" ]; then if [ -n "$strictDeps" ] && [[ "$f" = "$NIX_STORE"* ]]; then pathName=HOST_PATH else pathName=PATH fi fi </ins> if $(echo "$oldPath" | grep -q "/bin/env$"); then # Check for unsupported 'env' functionality: # - options: something starting with a '-'

Related discussion:
text: uses to determine the substitute for the shebang path. This selects the wrong path during cross-builds and results in x8664 binaries getting pulled in as dependencies to cross-built binaries that can't possibly use them at runtime. I don't know if we can reliably pick the correct /bin/sh without it being in the PATH envvar. I presume patchShebangs works fine for binaries that don't overlap with stdenv's and are included in buildInputs. If you cross-build some packages to ARM platforms, patchShebangs runs in the fixup phase and run , you'll see it points to the native /bin/sh rather than the cross one. I was considering a PR to just add to the cross build of glibc, but figured it'd be better if the root issue were fixed instead. System: "16.03pre75806." Nix version: nix-env (Nix) 1.12pre1234abcdef Nixpkgs version: (Gorilla)
/participate. (I've stumbled across this too.)
Is it safe to assume are the only paths that will ever realistically have this problem? If so, how and where would we pull in as a buildInput without it clobbering the native /bin/sh used by stdenv to run the builder? Once we're already executing , it's too late to find any s. This problem overlaps with another, , which is that crossDrvs clobber stdenv's binaries in the PATH. The best solution I can come up with is to manually include in of e.g. glibc, add logic in to not add to the PATH when crossbuilding, based on some new derivation attr like , then search during , independently of what's set in the PATH. Or we could just make smarter about importing /bin/ PATHs that contain elements of the stdenv, namely: .
is essential to fix this without greatly complicating bootstrapping.
don't forget to close. :)
Addressed in
Code change:
let # Release calendar: https://www.mesa3d.org/release-calendar.html # Release frequency: https://www.mesa3d.org/releasing.html#schedule <del> version = "21.0.1"; </del> <ins> version = "21.0.3"; </ins> branch  = versions.major version; self = stdenv.mkDerivation {

Related discussion:
text: Describe the bug VAAPI records repeated frames (see upstream bug report). upstream fix: To Reproduce Steps to reproduce the behavior: ... open OBS ... try recording using VAAPI (possible AMD hardware required?) ... watch replay Expected behavior full FPS. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
As for 21.0, the fix contained in upstream release = 21.0.2 so e.g. PR
Sadly a look at that thread, it's blocked because something broke, and they're not pushing it to 21.05, so this bug is going to exist until someone figures this out the regression, this patch is only one line of code, maybe it can be supplied as a patch until they get 21.0.3 working? Is there a way to build a patched mesa without rebuilding my entire desktop stack? It's currently stupidly slow on my computer when doing a packageOverride.
This will not be the only bug people will have to deal with on 21.05 unless we backport a more recent mesa (=21.1). Alternative we could also start to includes as well. Without it, this will lead to crashes in wine (incl. steam proton) when on some hardware ( for reference). While one can set as a workaround, it is hardly ideal and difficult to diagnose from within steam alone. Would it be possible to backport the mesa update currently in staging-next () once it is merged?
I don't know... this is hard. Maybe after a version has been a couple weeks in , we might be sufficiently confident that it won't make things worse overall.
I'm okay with backporting it, but probably as its own job set, just to get a better idea of regressions.
I'm not afraid of build-time regressions in this case. Those would be easy (to find). And mesa isn't such a big rebuild now anyway.
If it's been on unstable for a while, I guess I'm okay with it as well
I guess we can close this now, I haven't noticed any problems recently.
Code change:
# supporting it, or their bundled containerd systemd.enableUnifiedCgroupHierarchy = false; <ins> environment.systemPackages = [ config.services.k3s.package ]; </ins> systemd.services.k3s = { description = "k3s service"; after = mkIf cfg.docker [ "docker.service" ]; wantedBy = [ "multi-user.target" ]; <ins> path = optional config.boot.zfs.enabled config.boot.zfs.package; </ins> serviceConfig = { # See: https://github.com/rancher/k3s/blob/dddbd16305284ae4bd14c0aade892412310d7edc/install.sh#L197 Type = if cfg.role == "agent" then "exec" else "notify";

Related discussion:
text: Describe the bug nixpkgs has moved to unified cgroups (woo :tada:) as of recently (). Unfortunately, k3s fails to start correctly with unified cgroups without , which isn't included in a release yet. Until that lands in a release and nixpkgs is updated, it can be worked around by setting I intend to work on fixing this; I'll drop any notes along the way in this issue.
I've updated the title to be more specific, since my actual errors are coming from using k3s with , and the error is specifically about kubelet and docker's cgroup driver mismatching. I see that the unified cgroup PR did disable unified cgroups in the k3s module, so that probably should work before adding in the docker runtime. I need to do a little more investigation here.
Please let me know, if this is related: I'm trying to follow the wiki article on kubernetes on nixos: With the configs shown there I run into an error when starting The full error is very long, I've uploaded it here:
Thanks for looking into this.
Just tried the workaround mentioned above: Setting also fixes the problem for the kubernetes service
We have observed that unified cgroups also breaks Kubernetes-in-Docker for node images prior to 1.19. The observed behavior is that the kubelet fails to start, with the message: Also able to work around with
For k3s, the v1.20.4+k3s1 release includes unified cgroups support. It fixes my use of k3s, though I also had to set a flag in the nixos module ( to make docker+kubelet match). I've opened up a PR to bump the package (), and I'll make a separate PR to fix the nixos module to pass that arg. I think those two changes together should fix this issue. It sounds like there's other work to be done for other ways of running kubernetes on nixos too, but I think we should open separate issues for those to avoid conflating too many issues at once.
This would be the fix: I was not invested enough at the time to also write release notes, but if you want you can pick up the change.
see
This PR should also help:
This issue has been mentioned on NixOS Discourse.
Code change:
# supporting it, or their bundled containerd systemd.enableUnifiedCgroupHierarchy = false; <ins> environment.systemPackages = [ config.services.k3s.package ]; </ins> systemd.services.k3s = { description = "k3s service"; after = mkIf cfg.docker [ "docker.service" ]; wantedBy = [ "multi-user.target" ]; <ins> path = optional config.boot.zfs.enabled config.boot.zfs.package; </ins> serviceConfig = { # See: https://github.com/rancher/k3s/blob/dddbd16305284ae4bd14c0aade892412310d7edc/install.sh#L197 Type = if cfg.role == "agent" then "exec" else "notify";

Related discussion:
text: There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Code change:
checkFeatures = [ ]; patches = lib.optionals stdenv.isLinux [ <del> (runCommand "0001-dynamically-patchelf-binaries.patch" { CC = stdenv.cc; patchelf = patchelf; libPath = "$ORIGIN/../lib:${libPath}"; } '' </del> <ins> (runCommand "0001-dynamically-patchelf-binaries.patch" { CC = stdenv.cc; patchelf = patchelf; libPath = "${libPath}"; } '' </ins> export dynamicLinker=$(cat $CC/nix-support/dynamic-linker) substitute ${./0001-dynamically-patchelf-binaries.patch} $out  --subst-var patchelf 

Related discussion:
text: Running a fresh fails, the core message being: Steps to reproduce the behavior: a rust project (or if you already have one) Either the rustup gcc/ld to be patched for NixOS use, or rust to use the system gcc/ld. Please run and paste the result.
Actually, it looks like this is an issue specifically appearing with ; so I'll try to pass the message upstream.
Very specifically, introducing the issue, when it has been decided to switch from the system linker to . I suppose the new binaries should also be elf-patched?
Patching those binaries will make them execute, but they also need the applied so that the binaries they build will also get patched automatically.
Code change:
buildInputs = [ makeWrapper ]; postBuild = '' wrapProgram $out/bin/idris  <del> --run 'export IDRIS_CC=''${IDRIS_CC:-${lib.getBin gcc}/bin/gcc}'  --suffix LIBRARY_PATH : ${lib.makeLibraryPath [ gmp ]} </del> <ins> --run 'export IDRIS_CC=''${IDRIS_CC:-${stdenv.cc}/bin/cc}'  --set NIX_CC_WRAPPER_${stdenv.cc.infixSalt}_TARGET_HOST 1  --prefix NIX_CFLAGS_COMPILE " " "-I${lib.getDev gmp}/include"  --prefix NIX_CFLAGS_LINK " " "-L${lib.getLib gmp}/lib" </ins> ''; }

Related discussion:
text: Trying to compile fails with Install (not ) Create with run observe error
has gmp but doesn't have Base or Prelude (which is needed for stuff as simple as )
For reference, I think this issue is related:
You are meant to use to install additional packages with the compiler. I don't understand why the attribute it broken though from a brief look.
I bisected to the commit that caused this: This was in the idris update from 1.3.0 to 1.3.1 Currently looking into how this can be solved elegantly
In the meantime, is there a workaround for this?
Yes, the PR linked above () fixes this, but I'm not sure what to do with it, because it breaks Darwin in weird ways.
Code change:
hadoop3 = hadoop_3_3; hadoop = hadoop3; <ins> hashlink = callPackage ../development/interpreters/hashlink { }; </ins> io = callPackage ../development/interpreters/io { }; ivy = callPackage ../development/interpreters/ivy { };

Related discussion:
text: Project description Hashlink is a virtual machine used in Haxe/Heaps game projects. This is the same stack that shiro games and motion twin uses to make things like Dead Cells and Northgard. The full steps for installing heaps (which goes through dependencies) can be found , and one of the steps is to download hashlink and put it on the path. Metadata homepage URL: source URL: license: mit platforms: linux, mac, windows
I am on it, will try to compose a first draft. :-)
That was fast! I really appreciate it! I put in a few haxe-related package requests today, I'm so surprised no one else has requested them before! But once they're in we'll be happy! Not really looking to nix-ify my haxe projects yet since I imagine it'll be involved, but getting hashlink on the path in a package is a step in the right direction right? :) Really appreciate this, thank you!
I'm not really familiar with the Haxe ecosystem, but the Arch build for Hashlink suggested that this packaging task seemed simple enough (no complex build system, just a Makefile, no dependencies on other parts of the Haxe ecosystem) so that I could do it. Glad that I could be of help. :-) Thank you for your issue contributions! While the pull request is not yet merged, you can use hashlink as follows: (Be wary that commands like this can cause the execution of arbitrary code, so in principle one should use these only with trusted repositories.)
Thanks for your hard work!
how are things going with the PR? I think someone has asked a question on it, I don't know if that means that it's stalled from going in? Thanks again!
There are in fact issues with hashlink on NixOS I think - I think there's some libraries that are build with hashlink that are unhandled - there's an issue for this already as hinted in your PR:
Code change:
--bash <($out/bin/olaris-server completion bash)  --fish <($out/bin/olaris-server completion fish)  --zsh <($out/bin/olaris-server completion zsh) <ins> wrapProgram $out/bin/olaris-server --prefix PATH : ${lib.makeBinPath [ffmpeg]} </ins> ''; meta = with lib; {

Related discussion:
text: Olaris server requires ffmpeg to be available and raises an error when it can't be found: Steps to reproduce the behavior: olaris-server a library. The software runs correctly. There are two main ways to fix this: the software to use the full path to the ffmpeg dependency (ideally upstream). the program to add ffmpeg to its path. Please run and paste the result.
In fact it looks like it needs a custom image as it passes arguments that only exist on the modified version.
Actually it looks like the fork is no longer required: But this doesn't seem to be released yet. But probably is still a better option than packaging the custom ffmpeg.
yep, this looks like an easy fix EDIT: I was keen to try building the ffmpeg fork so that we can stick to a released version, however that proved prohibitively difficult, so tip of the default branch it is
no action required, but note the way I used in the pr and commit, means this issue would have autoclosed when the change merged
That is what happened.
sorry, I only saw this issue's update and assumed that you manually closed it; I assume most people involved in nixpkgs prs do not have merge perms, and github really needs to work on their ux. terribly sorry for the hassle, and assuming you were a more novice user.
No worries, GitHub really doesn't make it clear.
Code change:
else # The state directory is entirely empty which indicates a first start copy_tokens <del> fi        ''; </del> <ins> fi ''; </ins> configureRunner = writeScript "configure" '' if [[ -e "${newConfigTokenPath}" ]]; then echo "Configuring GitHub Actions Runner" args=( --unattended --disableupdate <del> --work "$RUNTIME_DIRECTORY" </del> <ins> --work "$WORK_DIRECTORY" </ins> --url ${escapeShellArg cfg.url} --labels ${escapeShellArg (concatStringsSep "," cfg.extraLabels)} --name ${escapeShellArg cfg.name}

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:
Code change:
hash = "sha256-5MP6X33Jfu97o5R1n6Og64Bv4ZMxVM0A8lXeQug+bNA="; }; <del> icons = let sparseCheckout = "/release/images/itch-icons"; in </del> <ins> sparseCheckout = "/release/images/itch-icons"; icons = </ins> fetchFromGitHub { <del> owner = "itchio"; repo = "itch"; rev = "v${version}-canary"; hash = "sha256-0AMyDZ5oI7/pSvudoEqXnMZJtpcKVlUSR6YVm+s4xv0="; sparseCheckout = [ sparseCheckout ]; } + sparseCheckout; </del> <ins> owner = "itchio"; repo = "itch"; rev = "v${version}"; hash = "sha256-jugg+hdP0y0OkFhdQuEI9neWDuNf2p3+DQuwxe09Zck="; sparseCheckout = [ sparseCheckout ]; } + sparseCheckout; in stdenvNoCC.mkDerivation (finalAttrs: { pname = "itch"; inherit version; </ins> <del> nativeBuildInputs = [ copyDesktopItems makeWrapper ]; </del> <ins> src = fetchzip { url = "https://broth.itch.ovh/itch/linux-amd64/${finalAttrs.version}/archive/default#.zip"; stripRoot = false; hash = "sha256-4k6afBgOKGs7rzXAtIBpmuQeeT/Va8/0bZgNYjuJhgI="; }; nativeBuildInputs = [ copyDesktopItems makeWrapper ]; </ins> desktopItems = [ (makeDesktopItem {

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:
, enableKernelPoll ? true , javacSupport ? false, javacPackages ? [ openjdk ] , odbcSupport ? false, odbcPackages ? [ unixODBC ] <del> , wxSupport ? true, wxPackages ? [ libGLU_combined wxGTK xorg.libX11 ] </del> <ins> , wxSupport ? !stdenv.isDarwin, wxPackages ? [ libGLU_combined wxGTK xorg.libX11 ] </ins> , preUnpack ? "", postUnpack ? "" , patches ? [], patchPhase ? "", prePatch ? "", postPatch ? "" , configureFlags ? [], configurePhase ? "", preConfigure ? "", postConfigure ? ""

Related discussion:
text: The current wxmac port fails to build. Build wxmac from latest git. wxWidgets uses some deprecated CoreFoundation functions, which are no longer there. Upstream version 3.0.4 still uses these functions. Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(sperber): nixpkgs:
That's very annoying! There has been a recent update of CF by that uses CF from Apparently they don't implement these deprecated APIs. We should be able to patch it to fix these references and use updated APIs. For now though you will probably be stuck on 18.03 or 18.09 if you need wxmac.
Yeah, I looked into that for a while, but the references to the now-unsupported FSRef type are pretty widespread in the wxmac codebase. :-( (I don't need wxmac directly, but erlang depends on it.)
Yeah, I patched those calls out of QT 4 but haven't gone and looked for other stuff that uses them.
Looking at source, it doesn't look like those functions are really used in any essential way. If you look at who calls , it doesn't really seem to be used anywhere much, and is used to set some icons. Or vice versa, but either way doesn't seem like it would be hard to patch out.
I was thinking the same thing, but my impression was that these are part of the public API of wxWidgets.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .