jiebi/CodeConvo huggingface dataset:
Change:
] else [] ) env)))); <del> mastodonEnv = pkgs.writeShellScriptBin "mastodon-env" '' </del> <ins> mastodonTootctl = pkgs.writeShellScriptBin "mastodon-tootctl" '' #! ${pkgs.runtimeShell} </ins> set -a export RAILS_ROOT="${cfg.package}" source "${envFile}" source /var/lib/mastodon/.secrets_env <del> eval -- "$@" </del> <ins> sudo=exec if [[ "$USER" != ${cfg.user} ]]; then sudo='exec /run/wrappers/bin/sudo -u ${cfg.user} --preserve-env' fi $sudo ${cfg.package}/bin/tootctl "$@" </ins> ''; in {

Discussion:
When one installs mastodon via the following minimal config: Then there is no obvious way to run tootctl. or any other login user doesn't have the executable by default, nor can this be enabled in an obvious way. is not a login user, so can't (and shouldn't?) log in as and execute . Steps to reproduce the behavior: mastodon as per minimal config above ... nope. ... nope. ... nope. ... nope. Any of: a setting such that is installed for that user an explanation in the docs what to do as a login user (probably bad idea?) Workaround: CC
I think upstream intends only to be run by the mastodon user. My way for doing that is just running and continuing in that shell. The reason why doesn't work is probably because sudo inherits PATH from the user you are coming from? I'm not sure I understand the concept of a login user enough. How would mastodon become a login user and why would that be a bad idea?
In the mastodon docs, it is described the following way: But is not possible, it gives the error They do recommend (which is what I meant by it shouldn't be a login user), but still they seem to do something different than nixos does. Maybe that's fine, and it would be helpful to document this somewhere, so people don't spend a long time trying to find it out.
This is default for almost all service users because they have no login shell. Use ` This is wrong. Sudo resets all path like variables like PATH and PYTHON PATH. Also inheriting needs to be turned on explicitly and PATH mist always ve inherited explicitly. Other services like nextcloud include a wrapper that sudos to the right user. This should be for mastodon, too.
Sounds like a good solution. Then we could make the command globally available.
That isn't? I would have expected that it is very similar to nextcloud-occ.
No currently it is only available to the mastodon user, so tootctl never gets called as the wrong user.
There is a hack in the nixos nextcloud-occ script that automatically sudoes if called by a different user. This could be adapted to tootctl I think.
Yes, this should be adapted. Changing the mastodon to a login user would not be the correct fix.
Change:
githubId = 2789926; name = "Imran Hossain"; }; <ins> iagoq = { email = "18238046+iagocq@users.noreply.github.com"; github = "iagocq"; githubId = 18238046; name = "Iago Manoel Brito"; keys = [{ longkeyid = "rsa4096/0x35D39F9A9A1BC8DA"; fingerprint = "DF90 9D58 BEE4 E73A 1B8C  5AF3 35D3 9F9A 9A1B C8DA"; }]; }; </ins> iammrinal0 = { email = "nixpkgs@mrinalpurohit.in"; github = "iammrinal0";

Discussion:
Describe the bug AdGuardHome has the meta platform , but is a . To Reproduce Try to run on (or any architecture other than ). It will fail with : Expected behavior should execute, so that it can be used. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I will try to get it instead of pulling a pre-compiled binary, but I'm not sure whether I'll get this solved. EDIT: Okay, that looks to be above my packaging skills, as the project consists of both a node component and a golang component, so it's nontrivial to package. An intermediate solution might be to use the architecture to determine the download URL, but that would make the src (and thus the hash) depend on the architecture. The downloads for different architectures .
Hotfix for aarch64 by using :
I marked this as stale due to inactivity. &rarr;
I also have the problem from the thread starter and I was wondering whether there is now official support for aarch64 (trying adguardhome on raspberrypi 3) or do I need to change smth in my config. I just use adguardhome as the inside of the systemPackages and I enable it. I also see this PR: .
the pr wasn't backported to 21.05. the pr will be in the 21.11 release which will be released today or tommorow afaik
great, thx for the info :)
Change:
# Test flaky because of our RPATH patching # https://github.com/NixOS/nixpkgs/pull/230965#issuecomment-1545336489 "compiler/codegen" <ins> # Test flaky "read" </ins> ] ++ lib.optionals (lib.versionAtLeast version "1.10") [ # Test flaky # https://github.com/JuliaLang/julia/issues/52739 "REPL" <ins> # Test flaky "ccall" </ins> ] ++ lib.optionals stdenv.isDarwin [ # Test flaky on ofborg "FileWatching"

Discussion:
This is regarding hydra build failure. Thanks to a matrix user for pointing out the hydra link! Thank you! Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
python3Packages.buildPythonPackage rec { pname = "auto-cpufreq"; <del> version = "1.6.1"; </del> <ins> version = "1.6.4"; </ins> src = fetchFromGitHub { owner = "AdnanHodzic"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-oz3C1150CPfT0kkx1x7VIX/Rm06dkjyxeDPFCRJaWNc="; </del> <ins> sha256 = "sha256-9WYuAWcJGosYEsnnkqvZLXXvqF+1nBEozh6F84Kit6w="; </ins> }; propagatedBuildInputs = with python3Packages; [ click distro psutil ];

Discussion:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it
Change:
, atk, at-spi2-atk, dbus , gdk-pixbuf, pango, cairo , expat, libdrm, mesa <del> , alsa-lib, at-spi2-core, cups }: </del> <ins> , alsa-lib, at-spi2-core, cups , libxkbcommon }: </ins> let LD_LIBRARY_PATH = lib.makeLibraryPath [

Discussion:
Steps to reproduce the behavior: on master Detected when reviewing locally Likely fixed by <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --unmaintained Please run and paste the result.

Package name: staruml Latest released version: 4.1.6 <!-- Search your package here: --- Current version on the unstable channel: 4.1.6 Current version on the stable/release channel: 4.1.6 <!-- 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. --No maintainers. Last update in version was automated by and last major package change by Note for maintainers: Please tag this issue in your PR.
Change:
<del> { stdenv, fetchurl, gtk-engine-murrine }: let themeName = "Ant-Dracula"; in stdenv.mkDerivation rec { pname = "ant-dracula-theme"; version = "1.3.0"; src = fetchurl { url = "https://github.com/EliverLara/${themeName}/releases/download/v${version}/${themeName}.tar"; sha256 = "00b8w69xapqy8kc7zqwlfz1xpld6hibbh35djvhcnd905gzzymkd"; }; propagatedUserEnvPkgs = [ gtk-engine-murrine ]; installPhase = '' runHook preInstall mkdir -p $out/share/themes/${themeName} cp -a * $out/share/themes/${themeName} rm -r $out/share/themes/${themeName}/{Art,LICENSE,README.md,gtk-2.0/render-assets.sh} runHook postInstall ''; meta = with stdenv.lib; { description = "Dracula variant of the Ant theme"; homepage = "https://github.com/EliverLara/${themeName}"; license = licenses.gpl3; platforms = platforms.all; maintainers = with maintainers; [ alexarice ]; }; } </del>

Discussion:
[Ant-Dracula] has moved to [Dracula]. [Dracula]: [Ant-Dracula]: Homepage: Repository:
Change:
in { sublime4 = common { <del> buildVersion = "4169"; x64sha256 = "jk9wKC0QgfhiHDYUcnDhsmgJsBPOUmCkyvQeI54IJJ4="; aarch64sha256 = "/W/xGbE+8gGu1zNh6lERZrfG9Dh9QUGkYiqTzp216JI="; </del> <ins> buildVersion = "4180"; x64sha256 = "pl42AR4zWF3vx3wPSZkfIP7Oksune5nsbmciyJUv8D4="; aarch64sha256 = "zRg2jfhi+g6iLrMF1TGAYT+QQKSNI1W4Yv1bz9oEXHg="; </ins> } { }; sublime4-dev = common { <del> buildVersion = "4175"; </del> <ins> buildVersion = "4178"; </ins> dev = true; <del> x64sha256 = "xncyxAaFJLLMko/iF6fhnpkOEHzD3nzWWGQCRK9srq4="; aarch64sha256 = "oqz1HASwmv0B1T3ZQBdIOZD9wYcHbni8tovW7jGp3KM="; </del> <ins> x64sha256 = "2eTdb5MzXK3QbAEzl1yxURj4m/PqGHPVnHZV2WzD6Jc="; aarch64sha256 = "NLLOB4WnujMx3+wf6Evi+yBWM6463EZoNL2wEdJA8BA="; </ins> } { }; }

Discussion:
Package name: sublime4 Latest released version: 4180 Current version on the unstable channel: 4169 Current version on the stable/release channel: 4169 <!-- 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]:
Please help test PR to ensure its working as you expect!
Change:
<ins> diff --git a/common/lib/modules/fglrx/build_mod/firegl_public.c b/common/lib/modules/fglrx/build_mod/firegl_public.c index b2242af..586129c 100755 --- a/common/lib/modules/fglrx/build_mod/firegl_public.c +++ b/common/lib/modules/fglrx/build_mod/firegl_public.c @@ -3249,7 +3249,7 @@ void ATI_API_CALL KCL_UnlockUserPages(unsigned long* page_list, unsigned int pag unsigned int i; for (i=0; i<page_cnt; i++) { -        page_cache_release((struct page*)page_list[i]); +        put_page((struct page*)page_list[i]); } } -- 2.9.2 </ins>

Discussion:
Two compilation errors are seen. I have a fix at , but I expect that it needs to be variablized to only apply these two new patches if building against a 4.6 (or greater) kernel, and I don't know how to do that. add'l keywords: ati_unfree
Compiler output:
You can add a simple conditional, e.g. similar to
Excellent, thanks for the pointer! Reworked and created a pull req.
Change:
harfbuzz, fontconfig, pkgconfig, ncurses, imagemagick, xsel, libstartup_notification, libX11, libXrandr, libXinerama, libXcursor, libxkbcommon, libXi, libXext, wayland-protocols, wayland, <del> which, dbus, </del> <ins> which, dbus, fetchpatch, </ins> Cocoa, CoreGraphics, Foundation,

Discussion:
Due to MacOS oddities does not work when executed as symlink() and hence, the wrapper installed via cannot work on MacOS. In fact, is unusable on MacOS whatever the content is. Any idea what could be done about this? Should we remove the directory altogether from the build output to prevent confusion?
I think the best thing to do here is just remove the symlink and use
If you wish to use a symlink, use one that points to kitty-deref-symlink
Change:
<del> { fetchurl, stdenv, curl, openssl, zlib, expat, perl, python, gettext, cpio, gnugrep, gzip </del> <ins> { fetchurl, stdenv, curl, openssl, zlib, expat, perl, python, gettext, cpio , gnugrep, gzip, openssh </ins> , asciidoc, texinfo, xmlto, docbook2x, docbook_xsl, docbook_xml_dtd_45 , libxslt, tcl, tk, makeWrapper, libiconv , svnSupport, subversionClient, perlLibs, smtpPerlLibs

Discussion:
Running with my still-quite-new nix environment, I get: Installing openssh fixes the problem for me, of course. But this means that git really ought to declare a dependency on openssh, no?
Hmm, currently I see two other alternatives: wrap all to have ssh in path (this seems the cleanest way), add it to , or or leave it as it is.
Or patch git to invoke ssh via an absolute path. (I'm not really fond of wrappers...)
Personally, I'd be very much in favor of patching git to call via an absolute path. At the same time, maintaining that patch over time is tedious and error-prone work, and I'd rather not be responsible for that. IMHO, patching SSH would be a feasible alternative only if we get that patch included upstream.
Has anyone taken a look at patching git to see how hard it will be?
There are two places. One is in connect.c where it reads GIT_SSH and then does Another is in git-gui where it does more or less the same, but in TCL.
I just found out that openssh isn't even a build input of git at the moment. :-)
I've decided to add a wrapper, since maintaining patches for references is going to be a burden. We still need to be able to specify public keys for ssh to pick them up.
your patch broke git-annex:
Reverted
that's an old build, now src is using https for sxiv
Is there a recommended solution for this now?
The recommended solution is to patch git, IMHO. It's not hard, as pointed out.
Triage: this issue does still exist on 16.03-beta:
Patched in
The solution to this issue is now causing a different issue on Fedora: () I'm not sure if we should really hard-code a SSH binary or if we should e.g. just reference a SSH binary as a fallback. Opinions welcome :)
FYI: is about to revert this and I currently believe that this is a good idea.
Change:
# built with, and use, that cross-compiled libc. gccCrossStageStatic = assert stdenv.targetPlatform != stdenv.hostPlatform; let libcCross1 = <del> if stdenv.targetPlatform.libc == "msvcrt" then targetPackages.windows.mingw_w64_headers </del> <ins> if stdenv.targetPlatform.libc == "msvcrt" then windows.mingw_w64_headers </ins> else if stdenv.targetPlatform.libc == "libSystem" then darwin.xcode else null; binutils1 = wrapBintoolsWith {

Discussion:
Cross compiling any package with or results in an infinite recursion error. The same error when just evaluating I get the same results with A resulted into this commit: By removing the part from that commit already fixes this issue. Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
should fix this, hopefully. /cc
Change:
rpiVersion = 4; }; <del> linux_4_4 = throw "linux 4.4 was removed because it reached its end of life upstream"; linux_4_9 = callPackage ../os-specific/linux/kernel/linux-4.9.nix { kernelPatches = [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper_updated kernelPatches.cpu-cgroup-v2."4.9" kernelPatches.modinst_arg_list_too_long ]; }; </del> <ins> linux_4_9 = throw "linux 4.9 was removed because it will reach its end of life within 22.11"; </ins> linux_4_14 = callPackage ../os-specific/linux/kernel/linux-4.14.nix { kernelPatches =

Discussion:
The Linux 4.9 LTS release will be EOL after 2023/01 and I hope we can remove it before the 22.11 release, so we don't carry it around until then. via cc kernel maintainer team
Thanks for the heads-up. I'd be fine with doing the removal right now (considering that it's LTS and having that one removed on stable may be an unpleasant surprise), but FWIW: we usually drop kernel releases when they get EOLed (also from stable branches), otherwise we wouldn't be able to provide non-LTS kernels on any stable branch anyways.
Change:
services.avahi.publish.enable = true; services.avahi.publish.userServices = true; <del> users.users.${cfg.user} = { description = "Shairport user"; </del> <ins> users = { users.${cfg.user} = { description = "Shairport user"; </ins> isSystemUser = true; createHome = true; home = "/var/lib/shairport-sync"; <ins> group = cfg.group; </ins> extraGroups = [ "audio" ] ++ optional config.hardware.pulseaudio.enable "pulse"; }; <ins> groups.${cfg.group} = {}; }; </ins> networking.firewall = mkIf cfg.openFirewall { allowedTCPPorts = [ 5000 ];

Discussion:
shairport-sync module creates the user without a default group, running into enabling causes the following error:
Change:
ln -sf "${cctools}/bin/$i" "$out/bin/$i" done <ins> ln -s ${llvm}/bin/llvm-dsymutil $out/bin/dsymutil </ins> ln -s ${binutils-unwrapped.out}/share $out/share ln -s ${cctools}/libexec $out/libexec

Discussion:
clang installed through nix doesn't correctly output DWARF data. system: host os: multi-user?: sandbox: version: channels(fghibellini): nixpkgs:
For reference, we use a dummy dsymutil script due to Apple not releasing the original source. This is found here: and . llvm has its own version that should be available to us soon. I'm not sure which version it is first released in.
Thanks for the quick answer! Based on I would think dsymutil is supposed to be Apple specific. Does the llvm release of dsymutil mean this (separate debug info linking) will become standard across operating systems or the llvm dsymutil is also supposed to be used only on OSX?
dsymutil is for MACH-O binaries only. I think OSX is the only place where those are used. You can do something similar on Linux with objcopy though: But this is a good reminder that we need to get the separate debug symbols to work on MacOS as well.
Change:
<ins> From 98285b17b3887de37b630da66f09a44f42ddbe01 Mon Sep 17 00:00:00 2001 From: Jakub Konka <kubkon@jakubkonka.com> Date: Tue, 25 Oct 2022 11:46:42 +0200 Subject: [PATCH] darwin: bump max macOS version to 13.0 --- lib/std/target.zig | 4 ++-- src/target.zig     | 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/lib/std/target.zig b/lib/std/target.zig index d791e3b0350..7fbad5baa3c 100644 --- a/lib/std/target.zig +++ b/lib/std/target.zig @@ -277,13 +277,13 @@ pub const Target = struct { .aarch64 => VersionRange{ .semver = .{ .min = .{ .major = 11, .minor = 6 }, -                                .max = .{ .major = 12, .minor = 0 }, +                                .max = .{ .major = 13, .minor = 0 }, }, }, .x86_64 => VersionRange{ .semver = .{ .min = .{ .major = 10, .minor = 13 }, -                                .max = .{ .major = 12, .minor = 0 }, +                                .max = .{ .major = 13, .minor = 0 }, }, }, else => unreachable, diff --git a/src/target.zig b/src/target.zig index 9e2d26dac65..fc585912c45 100644 --- a/src/target.zig +++ b/src/target.zig @@ -18,6 +18,7 @@ pub const available_libcs = [_]ArchOsAbi{ .{ .arch = .aarch64, .os = .windows, .abi = .gnu }, .{ .arch = .aarch64, .os = .macos, .abi = .gnu, .os_ver = .{ .major = 11, .minor = 0 } }, .{ .arch = .aarch64, .os = .macos, .abi = .gnu, .os_ver = .{ .major = 12, .minor = 0 } }, +    .{ .arch = .aarch64, .os = .macos, .abi = .gnu, .os_ver = .{ .major = 13, .minor = 0 } }, .{ .arch = .armeb, .os = .linux, .abi = .gnueabi }, .{ .arch = .armeb, .os = .linux, .abi = .gnueabihf }, .{ .arch = .armeb, .os = .linux, .abi = .musleabi }, @@ -73,6 +74,7 @@ pub const available_libcs = [_]ArchOsAbi{ .{ .arch = .x86_64, .os = .macos, .abi = .gnu, .os_ver = .{ .major = 10, .minor = 0 } }, .{ .arch = .x86_64, .os = .macos, .abi = .gnu, .os_ver = .{ .major = 11, .minor = 0 } }, .{ .arch = .x86_64, .os = .macos, .abi = .gnu, .os_ver = .{ .major = 12, .minor = 0 } }, +    .{ .arch = .x86_64, .os = .macos, .abi = .gnu, .os_ver = .{ .major = 13, .minor = 0 } }, }; pub fn libCGenericName(target: std.Target) [:0]const u8 { </ins>

Discussion:
I'm trying to install ncdu on darwin, which depends on zig; it has started failing to build in recent nixpkgs on the 22.11 track, though. Steps to reproduce the behavior: zig installs cleanly. <details<summaryoutput of nix log</summary<p</p</details Please run and paste the result.

Steps to reproduce the behavior: ncdu Please run and paste the result. `
Try adding ncurses to buildInputs for darwin.
It's already there - just not picked up for some reason. (I may have time to look at it soon, but was hoping to interest someone in the meantime :) )
ncdu is still broken in 22.11 on darwin
Change:
apply = steam: steam.override (prev: { extraEnv = (lib.optionalAttrs (cfg.extraCompatPackages != [ ]) { STEAM_EXTRA_COMPAT_TOOLS_PATHS = makeSearchPathOutput "steamcompattool" "" cfg.extraCompatPackages; <ins> }) // (optionalAttrs cfg.extest.enable { LD_PRELOAD = "${pkgs.pkgsi686Linux.extest}/lib/libextest.so"; </ins> }) // (prev.extraEnv or {}); extraLibraries = pkgs: let prevLibs = if prev ? extraLibraries then prev.extraLibraries pkgs else [ ];

Discussion:
worked for a little while but seems to stopped working Steps to reproduce the behavior: steam module: Observe The environment variable is missing and it doesn't show up in steam. should be present for Steam This was working for a few days I'm not sure what changed. <!-- 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]:
Searching it in printenv works fine for me But i can also confirm that its not visible via Can you confirm so war that its also set? Edit: also a small python prints out the environment variable correctly as Are you sure that this ever worked in the way you try it to? When starting a bash and then its also fine. I suspect, that exec is not scoping here right . When defining STEAMEXTRACOMPATTOOLSPATHS in my shell and then running your sample code i get which is supect, that it was working for you at some day, because you had set that from outside.
Make sure you're not adding the regular steam package to systemPackages; it may override any modifications done in . I've seen that anti-pattern employed before, we should probably disallow it somehow or nullify the negative effects. Perhaps we could give the option's steam package a higher priority for instance; buildEnv will use that one instead then.
This sadly didn't work either I don't think I ever set this in the past especially not outside. I do have Set though which I would imagine wouldn't effect it?
I did triple check and make sure the only method of installing steam is with
Curiously I just tried to set and that environment variable is missing from steam as well
is your config available for eval somewhere?
Yes it is. You'll have to drop as it's apart of a module.
I just fully removed the block and confirmed I don't have steam in my $PATH or desktop. Is it possible my FHS env is somehow corrupted or messed up? EDIT: I tried removing but that didn't seem to do anything either.
Okay I think I found it. This seems to happen when is enabled. I guess this is overwriting?

I submitted a PR () that hopefully should fix extests extraEnv. Could you verify if that fixes the problem for you?
Confirmed this solves the issue: Thanks for the help!
Change:
goa = callPackage ../development/tools/goa { }; <del> clingo = callPackage ../tools/misc/clingo { }; </del> <ins> gringo = callPackage ../tools/misc/gringo { }; </ins> gti = callPackage ../tools/misc/gti { };

Discussion:
The OCaml package manager () depends on an external solver. When the package was updated, it changed the compiler configuration, and a dependent package () of the solver () no longer compiled. The fix () uses a different monolithic package of the solver and its various tools (called "clingo") that for unknown reasons breaks : Install and attempt to run . System: Nix version: Nixpkgs version: