jiebi/CodeConvo huggingface dataset:
Change:
client = stdenv.mkDerivation (common // { name = "mariadb-client-${common.version}"; <del> outputs = [ "bin" "dev" "out" ]; </del> <ins> outputs = [ "out" "dev" "man" ]; </ins> propagatedBuildInputs = [ openssl zlib ]; # required from mariadb.pc <ins> patches = [ ./cmake-plugin-includedir.patch ]; </ins> cmakeFlags = common.cmakeFlags ++ [ "-DWITHOUT_SERVER=ON" <ins> "-DWITH_WSREP=OFF" </ins> ]; <del> preConfigure = common.preConfigure + '' cmakeFlags="$cmakeFlags  -DINSTALL_BINDIR=$bin/bin  -DINSTALL_SCRIPTDIR=$bin/bin  -DINSTALL_SUPPORTFILESDIR=$bin/share/mysql  -DINSTALL_DOCDIR=$bin/share/doc/mysql  -DINSTALL_DOCREADMEDIR=$bin/share/doc/mysql  " ''; # prevent cycle; it needs to reference $dev postInstall = common.postInstall + '' moveToOutput bin/mysql_config "$dev" moveToOutput bin/mariadb_config "$dev" </del> <ins> postInstall = '' rm -r "$out"/share/mysql rm -r "$out"/share/doc rm "$out"/bin/{msql2mysql,mysql_plugin,mytop,wsrep_sst_rsync_wan,mysql_config,mariadb_config} rm "$out"/lib/plugin/{daemon_example.ini,dialog.so,mysql_clear_password.so,sha256_password.so} rm "$out"/lib/{libmariadb.so,libmysqlclient.so,libmysqlclient_r.so} mv "$out"/lib/libmariadb.so.3 "$out"/lib/libmysqlclient.so ln -sv libmysqlclient.so "$out"/lib/libmysqlclient_r.so mkdir -p "$dev"/lib && mv "$out"/lib/{libmariadbclient.a,libmysqlclient.a,libmysqlclient_r.a,libmysqlservices.a} "$dev"/lib </ins> ''; enableParallelBuilding = true; # the client should be OK

Discussion:
mysqlupgrade requires availability of mysqlcheck, which is in the package In other operating systems they are separated - mysqlupgrade -, mysqlcheck - And when the server is installed the client is automatically installed.
Hmm, is there a reason not to make the client a dependency of the server? The only dependencies the client has that the server doesn't are and which any server should have (via openssh). How much space is saved by removing the client binaries?
So it seems the mysql_upgrade binary is hardcoded to expect the other binaries in the same directory: Probably the splitting works on other distros because the binaries all end up in /usr/bin anyway.
Need to build the package with server+client and only client? Is this variant bad?
I'm not sure what you mean. Can you check to see if the project cmake allows you to configure a different install PREFIX for the client/server?
Should I change the build of MariaDB, so that one package includes files for both server and client, and the other package only includes client files? I don't know how to configure this
19.09 milestone? If this and aren't resolved by then we will have to add the client binaries back into the server package.
- this variant optimal?
update MariaDB configuration, please check this variant.
Fixed, mariadb package includes server and client binaries.
Change:
description = "Cross-platform media player and streaming server"; homepage = "http://www.videolan.org/vlc/"; license = licenses.lgpl21Plus; <ins> maintainers = with maintainers; [ AndersonTorres ]; </ins> platforms = platforms.linux; }; }

Discussion:
package fails to build. Breaks building and subsequently Plasma 5 if is enabled. Steps to reproduce the behavior: of nixpkgs an error builds normally. Full build log: (Affects and Plasma 5) (Could be a issue)
This bisects to
Upstream issue:
Apply the not-yet-merged patch from upstream? I have no clue about the libcaca changes, but at least the patch looks like trivial renames: To me that sounds better than reverting the update (though my information is very limited):
Change:
TimeoutSec = "infinity"; Restart = "on-failure"; WorkingDirectory = "${cfg.packages.gitlab}/share/gitlab"; <del> ExecStart="${cfg.packages.gitlab.rubyEnv}/bin/sidekiq -C "${cfg.packages.gitlab}/share/gitlab/config/sidekiq_queues.yml" -e production -P ${cfg.statePath}/tmp/sidekiq.pid"; </del> <ins> ExecStart="${cfg.packages.gitlab.rubyEnv}/bin/sidekiq -C "${cfg.packages.gitlab}/share/gitlab/config/sidekiq_queues.yml" -e production"; </ins> }; };

Discussion:
states that it prints out the stripped name to the , but the stores the value in instead. The functionality in the documentation seems more convenient is there a reason not to switch to it?
I've noticed this as well. +1 for changing the implementation to print to stdout.
This one is interesting. There are maybe two dozen uses of that function, but it would be nice to change it. Maybe I’ll look into it tomorrow. Always happy to trigger a mass rebuild. :P
Was fixed in the meantime.
Change:
asc-key-to-qr-code-gif = callPackage ../tools/security/asc-key-to-qr-code-gif { }; <ins> go-audit = callPackage ../tools/system/go-audit { }; </ins> gopass = callPackage ../tools/security/gopass { }; gospider = callPackage ../tools/security/gospider { };

Discussion:
Project description go-audit is an alternative to the auditd daemon that ships with many distros. From : Metadata homepage URL: source URL: license: MIT platforms: Linux
Change:
postPatch = '' # Replace the shebangs for the various build scripts patchShebangs src <ins> # Compatability with OpenBLAS 0.3.21 substituteInPlace src/matrix/cblas-wrappers.h  --replace stptri_ LAPACK_stptri  --replace dtptri_ LAPACK_dtptri  --replace sgetrf_ LAPACK_sgetrf  --replace dgetrf_ LAPACK_dgetrf  --replace sgetri_ LAPACK_sgetri  --replace dgetri_ LAPACK_dgetri  --replace sgesvd_ LAPACK_sgesvd  --replace dgesvd_ LAPACK_dgesvd  --replace ssptri_ LAPACK_ssptri  --replace dsptri_ LAPACK_dsptri  --replace ssptrf_ LAPACK_ssptrf  --replace dsptrf_ LAPACK_dsptrf </ins> ''; configurePhase = ''

Discussion:
I'm trying to run the example script , but I get the following error: Steps to reproduce the behavior: into this flake: (Adapt paths in script) I'm trying out the software for the first time, so I didn't know what to expect, but I guess I didn't expect this error. I tried nixpkgs master first, but there, wouldn't build.
Change:
cargo-profiler = callPackage ../development/tools/rust/cargo-profiler {}; cargo-raze = callPackage ../development/tools/rust/cargo-raze { inherit (darwin.apple_sdk.frameworks) Security; <del> openssl = openssl_1_1; </del> }; cargo-readme = callPackage ../development/tools/rust/cargo-readme {}; cargo-semver-checks = callPackage ../development/tools/rust/cargo-semver-checks {

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: cargo-raze <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.12.0 desired version: 0.16.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers:
ty!
Change:
haveLibcxx = stdenv.cc.libcxx != null; isDarwinStatic = stdenv.hostPlatform.isDarwin && stdenv.hostPlatform.isStatic && lib.versionAtLeast release_version "16"; inherit (stdenv.hostPlatform) isMusl isAarch64; <ins> noSanitizers = !haveLibc || bareMetal || isMusl || isDarwinStatic; </ins> baseName = "compiler-rt"; pname = baseName + lib.optionalString (haveLibc) "-libc";

Discussion:
Steps to reproduce the behavior: (or try building pkgsLLVM.llvmPackages_git.compiler-rt) It seems like useLLVM causes the sanitizers to be disabled, not sure why this is the case as LLVM can rebuild itself with sanitizers enabled (outside of nixpkgs). See Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Ok, removing those useLLVM checks resulted in this:
cc may be helpful.
Unable to reproduce this.
Huh. I just ran into it with the new llvmPackages_git 19 -20 update in nixpkgs Hopefully the above nix file will be allow someone to reproduce it.
That seems to still produce the same result.
Turns out this is related to .
CC since this is related to sanitizers.
It's reproducible by building at version : Building version works fine:
Interesting, I wasn't using no-libc I think but I was doing it under pkgsLLVM and on aarch64-linux. That version doesn't look right.
Really? It seems to be the . Also, I have good news! Following the , I tried adding to , and it works:
Yeah, that's two weeks ago. Git is updated every week on Sunday. The PR for this week's update worked (although it only tests LLVM to clang). Interesting, I can get on this tonight.
Change:
''; }; <ins> rootCredentialsFile = mkOption  { type = types.nullOr types.path; default = null; description = '' File containing the MINIO_ROOT_USER, default is "minioadmin", and MINIO_ROOT_PASSWORD (length >= 8), default is "minioadmin"; in the format of an EnvironmentFile=, as described by systemd.exec(5). ''; example = "/etc/nixos/minio-root-credentials"; }; </ins> region = mkOption { default = "us-east-1"; type = types.str;

Discussion:
Describe the bug The minio service set environment variables - which are . This is the release currently used hence the breakage. Tested on To Reproduce Expected behavior It should be possible to login with the provided key.
thanks for the report! In future please tag maintainers so they actually see the issue, no one watches all nixpkgs issues :sweat_smile:
While the variables are deprecated, they are by minio. So I'm not sure this is really the cause of the breakage. However I will update the module to make use of the new variables and maybe even rename (or alias) the current options to make it consistent.
Yeah minio (on unstable) seems to be working just fine for me, but updating the variables seems to be the proper thing to do.
I implemented a the change in
Change:
<ins> #!/usr/bin/env nix-shell #!nix-shell -i bash -p libarchive curl common-updater-scripts set -eu -o pipefail cd "$(dirname "${BASH_SOURCE[0]}")" root=../../../../.. export NIXPKGS_ALLOW_UNFREE=1 version() { (cd "$root" && nix-instantiate --eval --strict -A "$1.version" | tr -d '"') } vivaldi_version_old=$(version vivaldi) vivaldi_version=$(curl -sS https://vivaldi.com/download/ | sed -rne 's/.*vivaldi-stable_([0-9]+.[0-9]+.[0-9]+.[0-9]+-[0-9]+)_amd64.deb.*/1/p') if [[ "$vivaldi_version" = "$vivaldi_version_old" ]]; then echo "nothing to do, vivaldi $vivaldi_version is current" exit fi # Download vivaldi and save hash and file path. url="https://downloads.vivaldi.com/stable/vivaldi-stable_${vivaldi_version}_amd64.deb" mapfile -t prefetch < <(nix-prefetch-url --print-path "$url") hash=${prefetch[0]} path=${prefetch[1]} echo "vivaldi: $vivaldi_version_old -> $vivaldi_version" (cd "$root" && update-source-version vivaldi "$vivaldi_version" "$hash") # Check vivaldi-ffmpeg-codecs version. chromium_version_old=$(version vivaldi-ffmpeg-codecs) chromium_version=$(bsdtar xOf "$path" data.tar.xz | bsdtar xOf - ./opt/vivaldi/vivaldi-bin | strings | grep -A2 -i '^chrome/' | grep '^[0-9]+.[0-9]+.[1-9][0-9]+.[0-9]+') if [[ "$chromium_version" != "$chromium_version_old" ]]; then echo "vivaldi-ffmpeg-codecs: $chromium_version_old -> $chromium_version" (cd "$root" && update-source-version vivaldi-ffmpeg-codecs "$chromium_version") fi </ins>

Discussion:
H.264 videos and specifically those (WebM and Theora are fine) don't play, which means that videos on Facebook and Twitter (at least) report an error. There are instructions for getting a patched version of the ffmpeg lib installed into your home folder which works, but ideally wouldn't be needed: to that the H.264 video don't work but the others do. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
What browser are you using? Works on Chromium, Firefox and qutebrowser (qtwebkit) on master for me.
Vivaldi, hence the title of the issue...
Oh, sorry, didn't know there's a browser called vivaldi.
Change:
fetchFromGitHub { owner = "itchio"; repo = pname; <del> rev = "v25.6.1-canary"; # Use ${version} if possible hash = "sha256-iBp7K7AW97SOlRa8N8TW2LcVtmUi9JU00fYUuPwKORc="; </del> <ins> rev = "v${version}-canary"; sha256 = "sha256-veZiKs9qHge+gCEpJ119bAT56ssXJAH3HBcYkEHqBFg="; </ins> sparseCheckout = [ sparseCheckout ]; } + sparseCheckout;

Discussion:
Steps to reproduce the behavior: itch system: host os: multi-user?: sandbox: version: channels(root): channels(username): nixpkgs:
Looks like there is an issue already posted for this package NixOS/nixpkgs and there was a PR (NixOS/nixpkgs which uses a canary build instead) posted. Since there is no stable update (the canary builds uses a separate config directory, which is also explained here ) this is still a upstream issue.

I can't update my system when itch should be installed: error: Package ‘electron-11.5.0’ in /nix/store/5wja3wj4lq4gijjgg2lx3966pf6lzijc-nixos- is marked as insecure, refusing to evaluate. Steps to reproduce the behavior: in no error also reproducible on unstable i guess electron needs an update or use a later electron version, if possible system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
It's an upstream issue, trying to use a newer Electron version makes Itch straight up not work (it gets stuck at the initial loading). unfortunately seems to be abandoned. There technically is a new version (25.6.1-canary), but it hasn't been distributed as a binary on , and looking at the commits it doesn't change much. There is really nothing that can be done here. You can do this on your if you don't care about the security risks:
Upstream issue:
Change:
in '' # avoid git dependency cp ${printVersion} build-aux/git-version-gen <del> # failing to build otherwise since glibc-2.38 sed '1i#include <string.h>' -i programs/dwg2SVG.c </del> ''; preConfigure = lib.optionalString (stdenv.isDarwin && enablePython) ''

Discussion:
Package name: libredwg Latest released version: 0.13.2 Current version on the unstable channel: 0.12.5.6313 Current version on the stable/release channel: 0.12.5.6313 Notify maintainers Tag: Changelog : Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
ping
Change:
<ins> import ./make-test-python.nix ({ pkgs, ... }: { name = "airsonic"; meta = with pkgs.lib.maintainers; { maintainers = [ sumnerevans ]; }; machine = { pkgs, ... }: { services.airsonic = { enable = true; maxMemory = 800; }; # Airsonic is a Java application, and unfortunately requires a significant # amount of memory. virtualisation.memorySize = 1024; }; testScript = '' def airsonic_is_up(_) -> bool: return machine.succeed("curl --fail http://localhost:4040/login") machine.start() machine.wait_for_unit("airsonic.service") machine.wait_for_open_port(4040) with machine.nested("Waiting for UI to work"): retry(airsonic_is_up) ''; }) </ins>

Discussion:
Describe the bug The Airsonic service fails to start. To Reproduce Steps to reproduce the behavior: = true; to your config. reveals the following error: Cannot load configuration class: which causes the application to enter a restart loop. <details<summaryError trace</summary<p</p</detailsExpected behavior It doesn't error, and instead runs successfully. Additional context It doesn't seem to be due to an Airsonic update that this started to fail, so my guess is that something got changed with the JRE. I think Airsonic will only work with JDK 8 (see: ), but I'm not very familiar with how Java works, so I'm not sure. Notify maintainers Metadata Fails on both of the following systems: Maintainer information:
Change:
"wandb" ]; <ins> # unmaintainable list of disabled tests passthru.skipBulkUpdate = true; </ins> meta = with lib; { description = "A CLI and library for interacting with the Weights and Biases API"; homepage = "https://github.com/wandb/wandb";

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit Contents of : This issue was automatically generated by . that created this issue. Internal tags:
This was caused by your commit . Could you please revert or push a fix?
I kindly ask you to help the python-updates runs which make the python package set maintainable by fixing this build failure by updating the ignored test list and considering to support python-updates runs in the future and proactively updating the packages you maintain. Thank you.
As evidenced by this issue, python-updates is breaking packages... the opposite of increasing maintainability! It is incumbent on commit authors to test their changes before merging and produce fixes/rollbacks when their changes result in breakages.
Having a severely outdated package set is also increasing the burden on everyone and maintaining packages harder which outweighs the occasional breakage. This is not always possible, otherwise merging any update to a package that has more than a few hundred reverse deps becomes impossible and we are basically halting nixpkgs to a grind.
Change:
ln -s $prog $out/bin/${prefix}$(basename $prog) done for prog in ${llvm}/bin/*; do <del> ln -s $prog $out/bin/${prefix}$(echo $(basename $prog) | sed -e "s|llvm-||") </del> ln -sf $prog $out/bin/${prefix}$(basename $prog) done rm -f $out/bin/${prefix}cat

Discussion:
Describe the bug The LLVM binutils package sets diff in the path to be llvm-diff. However, llvm-diff is not a replacement for POSIX diff, it's intended for diffing two LLVM IR files while ignoring non-semantic differences between the two. It doesn't operate as a drop in replacement for diff, so when trying to use a llvm-based stdenv to build anything that relies on diff the build will fail. To Reproduce Steps to reproduce the behavior: llvmPackages.bintools (affects 7, 8, 9 and 10) that diff now points to llvm-binutils-${VERSION}/bin/diff Expected behavior diff should continue to point to GNU diff which has the expected POSIX diff behaviour. Additional context There may be other tools in llvm-binutils that shouldn't be being linked without their llvm- prefix. also gets linked, and llvm-as is an LLVM IR -LLVM bitcode assembler not a system assembler. Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(davtru01): nixpkgs: Maintainer information:
:-) The current code in is:
Yeah, I would propose we just remove that line from each version. The llvm- prefixed binaries are not, in general, drop in replacements for the tools they share names with. In fact I think the only one that is is llvm-cxxfilt and that doesn't even have the same spelling as the tool it replaces when the prefix is removed.
I think these links were first in , so let's at least mention I actually don't even know much about the LLVM-related stuff.
Change:
# Until https://github.com/inkcut/inkcut/issues/105 perhaps pyqtgraph pythonocc-core <ins> typing-extensions </ins> ]; # qt_occ_viewer test requires enaml.qt.QtOpenGL which got dropped somewhere

Discussion:
Steps to reproduce the behavior: Depends on: [x]
ping, i think this can be closed as it builds on latest master
Thanks, indeed!
Change:
postPatch = stdenv.lib.optionalString stdenv.isDarwin '' substituteInPlace cmake/modules/AddLLVM.cmake  <del> --replace 'set(_install_name_dir INSTALL_NAME_DIR "@rpath")' "set(_install_name_dir INSTALL_NAME_DIR "$lib/lib")"  </del> <ins> --replace 'set(_install_name_dir INSTALL_NAME_DIR "@rpath")' "set(_install_name_dir)"  </ins> --replace 'set(_install_rpath "@loader_path/../lib" ''${extra_libdir})' "" '' # Patch llvm-config to return correct library path based on --link-{shared,static}.

Discussion:
Run , observe: Please run and paste the results.
Very weird... It must have come in from a recent update. You can find libLLDB in the lldb derivation:
/cc
Change:
environment.systemPackages = [ pkgs.udisks2 ]; <del> environment.etc = (mapAttrs' (name: value: nameValuePair "udisks2/${name}" { source = value; } ) configFiles) // { # We need to make sure /etc/libblockdev/conf.d is populated to avoid </del> <ins> environment.etc = (mapAttrs' (name: value: nameValuePair "udisks2/${name}" { source = value; } ) configFiles) // ( let libblockdev = pkgs.udisks2.libblockdev; majorVer = versions.major libblockdev.version; in { # We need to make sure /etc/libblockdev/@major_ver@/conf.d is populated to avoid </ins> # warnings <del> "libblockdev/conf.d/00-default.cfg".source = "${pkgs.libblockdev}/etc/libblockdev/conf.d/00-default.cfg"; "libblockdev/conf.d/10-lvm-dbus.cfg".source = "${pkgs.libblockdev}/etc/libblockdev/conf.d/10-lvm-dbus.cfg"; }; </del> <ins> "libblockdev/${majorVer}/conf.d/00-default.cfg".source = "${libblockdev}/etc/libblockdev/${majorVer}/conf.d/00-default.cfg"; "libblockdev/${majorVer}/conf.d/10-lvm-dbus.cfg".source = "${libblockdev}/etc/libblockdev/${majorVer}/conf.d/10-lvm-dbus.cfg"; }); </ins> security.polkit.enable = true;

Discussion:
The links in has been broken. Them link from , but in fact should be Steps to reproduce the behavior: in your NixOS configuration. your NixOS the , you will be told an error when opening the links in ! <!-- 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.

When I run new VM with , I see the following error in the journal: We probably need either or hardcode the path to the default config to the source code. nixpkgs:
(FWIW I'm seeing the same thing)
The default path is defined and used .
I marked this as stale due to inactivity. &rarr;
Still relevant
I'm affected by this. I'm assuming maybe this doesn't break anything because the built-in config is used per the expanded message: Maybe this can be closed then?
Change:
sha256 = "0n8il52yzbmvbkryrl8waz7hd9a2fdkw8zsrmhyh63jlvmmc31gf"; }; <ins> patches = [ # CVE-2019-20421 # included in next release (fetchpatch { url = "https://github.com/Exiv2/exiv2/commit/a82098f4f90cd86297131b5663c3dec6a34470e8.patch"; sha256 = "16r19qb9l5j43ixm5jqid9sdv5brlkk1wq0w79rm5agxq4kblfyc"; excludes = [ "tests/bugfixes/github/test_issue_1011.py" "test/data/Jp2Image_readMetadata_loop.poc" ]; }) ]; </ins> cmakeFlags = [ "-DEXIV2_BUILD_PO=ON" "-DEXIV2_BUILD_DOC=ON"

Discussion:
, CVSSv3=6.5 (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
See also: , ,
Patched on all three currently supported branches. See backlinks on MR .
Change:
in py.pkgs.buildPythonApplication rec { pname = "healthchecks"; <del> version = "3.4"; </del> <ins> version = "3.6"; </ins> format = "other"; src = fetchFromGitHub { owner = "healthchecks"; repo = pname; rev = "refs/tags/v${version}"; <del> sha256 = "sha256-hiuw7XfCDy+9fzuQMaeN9+XsENeBI1RNXy8IM1HIFhI="; </del> <ins> sha256 = "sha256-aKt9L3ZgZ8HffcNNJaR+hAI38raWuLp2q/6+rvkl2pM="; </ins> }; propagatedBuildInputs = with py.pkgs; [

Discussion:
I'm running (this specific package) on (config at ). This happened after upgrading from . Seems like a recent (?) django update has caused the service to fail due to breaking changes on django 5.1: Not really sure if this needs a specific upgrade path since it seems to be from migrations, but after the fix (see below) no migrations were run, so perhaps this happens every time. Steps to reproduce the behavior: healthchecks with that has failed (maybe?) should complete successfully. The error seems related to a , where they removed from . adds support for Django 5.1, so an upgrade to that version should fix the issue. Unfortunately, the automatic PR seems to be failing tests (). This is the fix upstream: I'm currently applying this fix to my config, see the commit ; it fixes the issue for now, and can run successfully: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for the report. Update is easy, it was just the test failing due to a slight change in wording on the site tested. See