jiebi/CodeConvo huggingface dataset:
Change:
let cfg = config.services.tailscale; <del> firewallOn = config.networking.firewall.enable; rpfMode = config.networking.firewall.checkReversePath; </del> isNetworkd = config.networking.useNetworkd; <del> rpfIsStrict = rpfMode == true || rpfMode == "strict"; </del> in { meta.maintainers = with maintainers; [ danderson mbaillie twitchyliquid64 ];

Discussion:
I really appreciate this message, but also would like to be able to disable it. Most of my Tailscale machines are not exit nodes, nor do they act as subnet routers, hence I would prefer to leave strict filtering enabled and also not have these warnings. It seems like a small thing, but these warnings tend to make me blind to other new, more relevant warnings. I'm hacking on something here:
Thanks for raising this, have been ignoring this issue for ages and meaning to try to do something about it but never got around to it :sweat_smile:
Hah now I'm going to ask you for feedback - how does sound for the option name? It's wordy but I can't think of anything much better. ? but then that hits the issue where it removes the chance for users to see / opt-out of future warnings.
sounds fine, not aware of any existing convention for options to silence warnings.
Change:
unrtf = callPackage ../tools/text/unrtf { }; <del> unrpa = with python38Packages; toPythonApplication unrpa; </del> <ins> unrpa = with python3Packages; toPythonApplication unrpa; </ins> untex = callPackage ../tools/text/untex { };

Discussion:
Steps to reproduce the behavior: Happens on master (commit ) and unstable (). Please run and paste the result.
May I ask why you're interested in the version for Python 3.8?
-(extracting icon for desktop file) -requires python38: -------requires a matching Meson Edit: This seems to be a recent breakage, as it built fine on the version of Nixpkgs that PR was based on.
Python 3.8 is EOL and maintaining it is not sustainable. Please find an alternative.
uncompyle6 is an optional dependency, it should work fine without.
Change:
stdenv.mkDerivation rec { pname = "emscripten"; <del> version = "3.1.55"; </del> <ins> version = "3.1.64"; </ins> llvmEnv = symlinkJoin { name = "emscripten-llvm-${version}";

Discussion:
Package name: emscripten Latest released version: 3.1.57 <!-- Search your package here: --- Current version on the unstable channel: 3.1.51 Current version on the stable/release channel: 3.1.47 <!-- 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]:
tl;dr: 3.1.57 is not currently compatible with the version of llvm in tree (18.1.5). The latest compatible version with llvm 18.1.5 appears to be Emscripten 3.1.54. The emscripten nixpkg (3.1.51) currently uses an LLVM17 environment which needs be migrated to LLVM18. The configuration as it exists today doesn't work in some cases. (Godot4.3dev6 web template builds failed missing in , prompting finding this issue) Emscripten 3.1.51 seems to be compatible with the LLVM 18.1.5 currently in nixpkgs unstable. Emscripten 3.1.59 (current as of this comment) and 3.1.57 are not compatible with that version of LLVM (In my usage, ran into errors with and ). These flags were introduced in Emscripten 3.1.55 making the last compatible version against the current in-tree dependencies 3.1.54. <details<summaryThis override was able to successfully build the godot4.3dev6 web templates using Emscripten 3.1.54</summary<p</p</details
Change:
pos = builtins.unsafeGetAttrPos "pname" args; <del> passthru.updateScript = gitUpdater { inherit rev-prefix odd-unstable patchlevel-unstable; }; </del> <ins> passthru = { updateScript = gitUpdater { inherit rev-prefix odd-unstable patchlevel-unstable; }; } // passthru; </ins> meta = with lib; { homepage = "https://gitlab.xfce.org/${category}/${pname}"; license = licenses.gpl2Plus; # some libraries are under LGPLv2+ platforms = platforms.linux; <del> }; </del> <ins> } // meta; </ins> }; <del> publicArgs = removeAttrs args [ "category" "pname" "sha256" ]; </del> <ins> publicArgs = removeAttrs args [ "category" "sha256" ]; </ins> in <del> stdenv.mkDerivation (recursiveUpdate template publicArgs // concatAttrLists [ template args ]) </del> <ins> stdenv.mkDerivation (publicArgs // template // concatAttrLists [ template args ]) </ins> # TODO [ AndersonTorres ]: verify if it allows using hash attribute as an option to sha256

Discussion:
Looking at my filed ofborg does not ping in most cases. I am thinking of ofborg pings people, or the above command does not print (I guess) No response. No response.
Change:
{command}`cat /sys/class/block/zram*/comp_algorithm` ''; }; <ins> writebackDevice = lib.mkOption { default = null; example = "/dev/zvol/tarta-zoot/swap-writeback"; type = lib.types.nullOr lib.types.path; description = lib.mdDoc '' Write incompressible pages to this device, as there's no gain from keeping them in RAM. ''; }; </ins> }; }; config = lib.mkIf cfg.enable { <ins> assertions = [ { assertion = cfg.writebackDevice == null || cfg.swapDevices <= 1; message = "A single writeback device cannot be shared among multiple zram devices"; } ]; </ins> system.requiredKernelConfig = with config.lib.kernelConfig; [ (isModule "ZRAM") ];

Discussion:
One of the features of zram (and of systemd-zram-generator) is that a swap partition (and hopefully someday in the future a swap file too) can be used to store incompressible pages instead of holding them in ram. It's (you're the last person I saw touch the zramSwap module.) Please run and paste the result.
Our current zram module is implemented by retrofitting the old interface for our own set of bash scripts onto zram-generator, thus it's only possible to create multiple zram devices of identical configurations. However it should be illegal to share a single backing device among multiple zram devices, leaving us two choices in implementing this: allow creating a single zram device when backing device is set the module to expose the full features of zram-generator What's your opinion?
:thinking: It's not stated that the module uses zram-generator under the hood, and I'd say that I don't really think a lot of people use multiple zram devices, so perhaps  is fine.
Change:
''; meta = with lib; { <del> description      = "Multi pod and container log tailing for Kubernetes"; homepage         = "https://github.com/wercker/stern"; license          = licenses.asl20; maintainers      = with maintainers; [ mbode ]; platforms        = platforms.unix; </del> <ins> description = "Multi pod and container log tailing for Kubernetes"; homepage = "https://github.com/stern/stern"; license = licenses.asl20; maintainers = with maintainers; [ mbode preisschild ]; platforms = platforms.unix; </ins> }; }

Discussion:
We should replace the discontinued source with the more active fork . wrecker/stern hasn't received any commits since 2019. The maintainer of stern doesn't work at wercker anymore, and it seems no one else there is maintaining it (wercker/stern). The community has since moved to stern/stern with improvements to the original source. Project description Multi pod and container log tailing for Kubernetes Metadata homepage URL: source URL: license: Apache-2.0 platforms: unix
Change:
# correct system. unset system sed -e "232s/LLVM_STATIC_LIBS/LLVMLIBS/" -i compiler/Makefile.unix <ins> # The makefile sets LLVM_<version> depending on the current llvm # version, but the detection code is quite brittle. # # Failing to properly detect the llvm version means that the macro # LLVM_VERSION ends up being the raw output of `llvm-config --version`, while # the code assumes that it's set to a symbol like `LLVM_35`.  Two problems result: # * <command-line>:0:1: error: macro names must be identifiers.; and # * a bunch of undefined reference errors due to conditional definitions relying on #   LLVM_XY being defined. # # For now, fix this by 1) pinning the llvm version; 2) manually setting LLVM_VERSION # to something the makefile will recognize. sed '52iLLVM_VERSION=3.7.0' -i compiler/Makefile.unix </ins> ''; # Remove most faust2appl scripts since they won't run properly

Discussion:
a few weeks ago I was able to successfully install faust2 (), but today it looks like its broken. I'm on the unstable channel.
cc
Thanks for noticing. Good to know there are more faust users on NixOS. I don't know what the problem is, and unfortunately atm I don't have time to debug either. Maybe can help.
I was pleasantly surprised to find faust2 already on nixpkgs! If I get time I'll look at it too, but not sure where to start re debugging the package.
FWIW, I was able to install the working version of the package from hydra! Took me a while to think of doing that. Package is here:
Hehe, closure-size version of it, but the fact remains that some changes have broken the build later. The ability to easily use older builds in the meantime is a hallmark of nix...
FWIW: I just built faust 2 on 15.09
I think the problem is that the makefile passes to gcc, which ends up being an invalid macro name (cannot start with a digit), resulting in the error.Patching out from makes the problem go away. Beyond that hurdle is another issue with undefined references. There are some conditonals in a header file that depend on macro symbols that are never defined, resulting in undefined reference errors; I manually patched the makefile to pass these as appropriate for the detected llvm version. Feels like a terrible hack, but it fixes the build (on my system, anyway). Does this sound crazy or should I create a PR for this?
Change:
mkDerivation { name = "kimageformats"; nativeBuildInputs = [ extra-cmake-modules ]; <del> buildInputs = [ karchive openexr qtbase ]; </del> <ins> buildInputs = [ karchive openexr libavif qtbase ]; </ins> outputs = [ "out" ]; # plugins only CXXFLAGS = "-I${getDev ilmbase}/include/OpenEXR"; }

Discussion:
The library has support for AVIF since the . that AVIF support. The support is optional however, and requires the libavif library to be present. I imagine one needs to package for nixos, then add it to the / similarly to how it's done for openexr already.
libavif is already packaged in . So maybe just adding to in is enough? Can you try if that works for you and if it did send a pull request?
interesting. I'll give it a try.
So I've done some experimenting locally, and apparently if I only add libavif it still doesn't recognize avif files. It does create a file meaning that it successfully created a plugin, but when I try to open avif files using gwenview, it gives an error that it can't open files. If I try to open an heif file however, it shows a different error: it complains that it can't open files. So maybe it has the module, but no clue it can use the module because it doesn't know the mime type. Also, running returns the correct mime type for jpg and heif files, but does not return the correct mime type for avif files. I've checked and apparently the shared-mime-info package points to the 1.13.1 release from September 2019, but the . The most recent release is 2.1 from Dec 31 2020. I suspect that an update of the shared-mime-info package should fix this, but need to test it. cc maintainer of shared-mime-info.
I've looked a bit into the question of updating shared-mime-info. An update to 2.1 needed some adjustments to accommodate for the meson migration and a backport of a patch to not hit the internet during build. After that the package built but there was a test failure in one of the dependents... When I backported the AVIF patch for 1.13.1, I realized that basically everything depends on shared-mime-info. I eventually ran out of disk space during the build. I think that waiting for a regular update of shared-mime-info would be best.
Also, it seems that the CXXFLAGS thing isn't needed.
I've tested the patch locally and it works (needed to wait until there were sufficient hydra cache results for ).

I've made a PR:
KImageFormat does currently not seem build: See comments in PR of libavif upgrade: The following fix, which looks to be included in seems relevant:
Change:
ngt = callPackage ../development/libraries/ngt { }; <del> nheko = libsForQt5.callPackage ../applications/networking/instant-messengers/nheko { }; </del> <ins> nheko = libsForQt5.callPackage ../applications/networking/instant-messengers/nheko { # https://github.com/NixOS/nixpkgs/issues/201254 stdenv = if stdenv.isLinux && stdenv.isAarch64 && stdenv.cc.isGNU then gcc11Stdenv else stdenv; }; </ins> nomacs = libsForQt5.callPackage ../applications/graphics/nomacs { };

Discussion:
Steps to reproduce the behavior: i noticed the break after the nheko 0.10.2 -0.11.0 upgrade landed in nixos-unstable: hydra failure (click for the build log): build is currently broken in both master () and has been fixed in nixos-22.11, see for having initiated the backport. tagging as maintainer of both mtxclient and nheko. Please run and paste the result.
tested against the outstanding mtxclient 0.9.0 -0.9.1 PR: still broken.
I have no idea why a standard library would depend, let alone be missing, on a different architecture.
Likely due to us using outdated gcc (gcc9) on aarch64-linux. The story is complicated, but is being addressed.
Forcing it to use gcc11Stdenv may fix the issue.
It seems so: I tested by cross-compiling mtxclient (I don't have an aarch64 system).
Opened
Great... now coeurl fails to build. EDIT: Fixed, but nheko is still broken.
hope nobody minds this extra notification that is me thanking you all for jumping in so readily to fix things, even for someone you’ve never met. anyone reading this: what you’re doing here has more impact than you know.
Change:
{ environment = { etc = mapAttrs' (name: { packages, ... }: { <del> name = "per-user-pkgs/${name}"; value.source = pkgs.symlinkJoin { name = "per-user-pkgs.${name}"; </del> <ins> name = "profiles/per-user/${name}"; value.source = pkgs.buildEnv { name = "user-environment"; </ins> paths = packages; <ins> inherit (config.environment) pathsToLink extraOutputsToInstall; inherit (config.system.path) ignoreCollisions postBuild; </ins> }; }) (filterAttrs (_: { packages, ... }: packages != []) cfg.users); <del> profiles = ["/etc/per-user-pkgs/$LOGNAME"]; </del> <ins> profiles = ["/etc/profiles/per-user/$USER"]; </ins> }; } ];

Discussion:
Like that: Cf. This way, we exactly reproduce what building the global system does. Only some files should be symlinked to from within a profile, and we already know which ones. Using and inheriting its args like that does just that. Original PR using : . /cc System: 17.09 Sandboxing enabled: yes
Change:
src = fetchurl { url = "mirror://kernel/linux/kernel/v6.x/linux-${kversion}.tar.xz"; <del> sha256 = "1ry7dp39010hfja1wial6r6q6ilgygwm7gdz22bg4rzaycwam7b2"; </del> <ins> sha256 = "02mj394ina3npp6qqinc4pc6afp5pg1rlbjc90g4p902d29jjwj0"; </ins> }; kernelPatches = let rt-patch = { name = "rt"; patch = fetchurl { url = "mirror://kernel/linux/kernel/projects/rt/${branch}/older/patch-${version}.patch.xz"; <del> sha256 = "1vvn21bprsqqzmqvcmj1jx3xn1dc6kih5fib9qpcyrh0j1c7s077"; </del> <ins> sha256 = "0axy543q47xv5nsrw6prmy9dqvbp27wkn2brwygl05nl8grjvhr8"; </ins> }; }; in [ rt-patch ] ++ kernelPatches;

Discussion:
Apparently upstream stable kernels 6.1.65 (NixOS 23.11 default) and .64 have a cherry-picking bug that can create data corruption on ext4 Probably NixOS should update to 6.1.66 (released 2 days ago) as soon as possible
Looks like this was already dealth with: Currently building on Hydra:
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:
I believe the realtime kernel from the branch still contains this bug? Made an issue:
Change:
libxslt docbook-xsl-nons docbook_xml_dtd_42 <ins> wrapGAppsHook </ins> ]; buildInputs = [

Discussion:
Describe the bug When I try to pull from a remote repository using ostree, it fails. Note that flatpak is not affected, just ostree. To Reproduce Steps to reproduce the behavior: Expected behavior It would download the source files of org.freedesktop.Sdk (actually I'm not sure I'm doing that part right, but the TLS error seems like a Nix problem) Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(qolen): nixpkgs: Maintainer information:
This is a problem with not getting set properly. Should we wrap the ostree binary?
When I set in the derivation, as i've seen suggsted, I get "Failed to load TLS database: Failed to load system trust store: Error while reading file." instead
(seems to be the same issue as )
Change:
hash = "sha256-oEH4GlSV+642TGSJJhV4yzydh1hAQZfzwaiPAZFNQtI="; }; <ins> patches = [ (fetchpatch { name = "gmic-3.2.1-fix-system-gmic.patch"; url = "https://github.com/GreycLab/gmic/commit/9db3f6a39d9ed67b4279654da88993a8057575ff.patch"; hash = "sha256-JznKCs56t6cJ4HLqlhMZjSOupEB8cdkn3j6RgZpcpzo="; }) ]; </ins> # TODO: build this from source # https://github.com/dtschump/gmic/blob/b36b2428db5926af5eea5454f822f369c2d9907e/src/Makefile#L675-L729 gmic_stdlib = fetchurl {

Discussion:
We broke gmic-qt during the bump. After contacting upstream, it seems like the cmake build is not maintained anymore: They migrated to . We should align with them and rewrite a qmake derivation for gmic-qt. Edit: jtojnar advise not to migrate to qmake but instead fix the cmake issue.
Any idea what I can do so I can build my system while this is a WIP?
Install the build from an older version of nixpkgs where the package you want still builds properly. The version in branch should be building properly. For Flakes: For Non-Flake:
Thank you so much!! That section of the wiki described exactly what I was trying to do!
I just posted an upstream PR to fix this:
I've opened with a proper fix if anyone here would like to do some testing (it works for me now)

Steps to reproduce the behavior: Full log: Package built successfully in . Package failed in . I assume package failed to built somewhere in between these two pull request. Please run and paste the result.
Possibly needs update like
tried but had a compilation issue: Error:
Change:
<ins> { mkKdeDerivation, lib, fetchurl, boost, eigen, imath, libetonyek, libgit2, libodfgen, librevenge, libvisio, libwpd, libwpg, libwps, okular, perl, pkg-config, poppler, qtkeychain, qtsvg, }: mkKdeDerivation rec { pname = "calligra"; version = "4.0.1"; src = fetchurl { url = "mirror://kde/stable/calligra/calligra-${version}.tar.xz"; hash = "sha256-1AH15z9PG9wLNUjqGlCwrBd4we3jCmozWUTtf72I2V8="; }; extraBuildInputs = [ boost eigen imath libetonyek libgit2 libodfgen librevenge libvisio libwpd libwpg libwps okular poppler qtkeychain qtsvg ]; extraNativeBuildInputs = [ perl pkg-config ]; # Recommended by the upstream packaging instructions. RELEASE_BUILD disables # unmaintained components, like Braindump, from being built, and KDE_NO_DEBUG_OUTPUT # is supposed to improve performance in the finished package. extraCmakeFlags = [ (lib.cmakeBool "RELEASE_BUILD" true) (lib.cmakeFeature "CMAKE_CXX_FLAGS" "-DKDE_NO_DEBUG_OUTPUT") ]; meta = { maintainers = with lib.maintainers; [ ebzzry zraexy sigmasquadron ]; license = with lib.licenses; [ gpl2 lgpl2 ]; mainProgram = "calligralauncher"; }; } </ins>

Discussion:
Package name: calligra Latest released version: 4.0.0 <!-- Search your package here: --- Current version on the unstable channel: 3.2.1 Current version on the stable/release channel: 3.2.1 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Github moment. Completed in .
Change:
<del> Add channel parameter to cfg80211_ibss_joined call --- a/src/wl/sys/wl_cfg80211_hybrid.c +++ b/src/wl/sys/wl_cfg80211_hybrid.c @@ -1841,7 +1841,12 @@ wl_notify_connect_status(struct wl_cfg80211_priv *wl, struct net_device *ndev, wl_get_assoc_ies(wl); memcpy(&wl->bssid, &e->addr, ETHER_ADDR_LEN); wl_update_bss_info(wl); +#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 15, 0) cfg80211_ibss_joined(ndev, (u8 *)&wl->bssid, GFP_KERNEL); +#else +			cfg80211_ibss_joined(ndev, (u8 *)&wl->bssid, +			                     &wl->conf->channel, GFP_KERNEL); +#endif set_bit(WL_STATUS_CONNECTED, &wl->status); wl->profile->active = true; } </del>

Discussion:
It will likely be enough to grab a patch from another distro. Maybe I'll look into it tomorrow.
Builds now, but I didn't try running it.
Change:
, curl , openssl , file <ins> , darwin </ins> , gitUpdater }: <ins> let inherit (darwin.apple_sdk.frameworks) Cocoa; in </ins> stdenv.mkDerivation rec { pname = "pwsafe"; version = "1.16.0"; # do NOT update to 3.x Windows releases

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 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! --- : when I search the pulls for , I see . It's not obvious to me why this is relevant, but see below name: <!-- The current version can be found easily with the same process than 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: 3.53.0 desired version: <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: This fails to build for me, crashing out on the build of (which is presumably where the link to pull comes from). Given this is apparently a failure in a dependency, it may be that will automatically start building again once this is resolved. If that's so, then this report is redundant; in which case, apologies. But I'll add it nonetheless in case the fix is not that automatic (I'm a bit vague about how fixes propagate around the wonderful wonderland of Nix).

clang++ -mmacosx-version-min=10.7 -c -o htmldllhelpdata.o -DWXOSXCOCOA -DWXBUILDING -I./src/regex -DWXUSINGDLL -DWXMAKINGDLLHTML -dynamic -fPIC -DPIC -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wno-deprecated-declarations -DFILEOFFSETBITS=64 -I/private/tmp/nix-build-wxwidgets- -I./include -DASSERTMACROSDEFINEVERSIONSWITHOUTUNDERSCORES=1 -O2 -fno-strict-aliasing -fno-common -fvisibility=hidden -fvisibility-inlines-hidden fatal error: 'AVFoundation/AVFoundation.h' file not found #import <AVFoundation/AVFoundation.h^~~~~ 1 error generated. make: [Makefile:: mediadllosxcocoa_mediactrl.o] Error 1 make: Waiting for unfinished jobs.... builder for '/nix/store/wm81bmbkzk2ziyk5v3spdz4647n1v5vn-wxwidgets-' failed with exit code 2 cannot build derivation '/nix/store/y5b7m6vlp8l5046sf7g41bz88w2dv9gn-pwsafe-': 1 dependencies couldn't be built error: build of '/nix/store/y5b7m6vlp8l5046sf7g41bz88w2dv9gn-pwsafe-' failed This is with the unstable channel fully updated: $ nix-env -qa --drv-path --out-path pwsafe pwsafe-3.53.0 /nix/store/y5b7m6vlp8l5046sf7g41bz88w2dv9gn-pwsafe- /nix/store/lvikq70mprd98ny90glpsh04llzs77nz-pwsafe-3.53.0 Platform: macOS 10.15.7 (Catalina). Please tag this issue in your PR.
I just tested it on Linux, there it works just fine. Thank you for your report, and sorry that I cannot be of further assistance!
I marked this as stale due to inactivity. &rarr;