jiebi/CodeConvo huggingface dataset:
Change:
ldap-client = dontCheck super.ldap-client; lensref = dontCheck super.lensref; lvmrun = disableHardening (dontCheck super.lvmrun) ["format"]; <ins> math-functions = if pkgs.stdenv.isDarwin then dontCheck super.math-functions # "erf table" test fails on Darwin https://github.com/bos/math-functions/issues/63 else super.math-functions; </ins> matplotlib = dontCheck super.matplotlib; memcache = dontCheck super.memcache; metrics = dontCheck super.metrics; milena = dontCheck super.milena; <ins> mockery = if pkgs.stdenv.isDarwin then overrideCabal super.mockery (drv: { preCheck = "export TRAVIS=true"; }) # darwin doesn't have sub-second resolution https://github.com/hspec/mockery/issues/11 else super.mockery; </ins> modular-arithmetic = dontCheck super.modular-arithmetic; # tests require a very old Glob (0.7.*) nats-queue = dontCheck super.nats-queue; netpbm = dontCheck super.netpbm;

Discussion:
See It blocks the nixpkgs-unstable channel. The package has no .
Actually, the output is weird. It's like... a tiny difference in float precision? :thinking: OK, filed upstream:
Change:
ZONEINFO = "${pkgs.tzdata}/share/zoneinfo"; }; serviceConfig = { <ins> Type = "exec"; # When credentials are used with systemd before v257 this is necessary to make the service start reliably (see systemd/systemd#33953) </ins> ExecStart = "${cfg.package}/bin/influxd --bolt-path ${STATE_DIRECTORY}/influxd.bolt --engine-path ${STATE_DIRECTORY}/engine"; StateDirectory = "influxdb2"; User = "influxdb2";

Discussion:
Steps to reproduce the behavior: shows that the job has been broken for a while (about 2 months), and possibly also a bit flaky. I'm not sure if this is enough context -- but here's a part of the log: I wanted to fix but now getting somewhat blocked because the tests don't work. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Yes, it's flaky. With some re-runs the test passes. For the last two months though, the build has been faililng in Hydra for like 99% of the builds.
Looks good to me. I have an idea how to fix the flakyness, since I encountered something similar in kanidm recently. Actually, you can just try to delete the whole block. I originally this to speed up stopping in case of an early failure but found this to be the problem in kanidm too. There seems to be some kind of data race in systemd service creation where the main pid is not yet allocated (although it somehow must be known already...) while the post start script already runs. I can't explain the problem but we don't need that block so taking this out should resolve it.
I tried removing the block from , but the result is the same (failure):
Hmm this seems completely unrelated to our preStart script, as this error occurs way before that even runs. I'm not sure what is happening here exactly, but I'll try to figure it out separately. It doesn't make sense IMO to block this change on that.
Change:
<del> diff --git a/base/numerics/safe_math_shared_impl.h b/base/numerics/safe_math_shared_impl.h index 99f230ce7e9a..de2415d402f5 100644 --- a/base/numerics/safe_math_shared_impl.h +++ b/base/numerics/safe_math_shared_impl.h @@ -21,8 +21,7 @@ #if !defined(__native_client__) &&                          ((defined(__clang__) &&                                 ((__clang_major__ > 3) ||                             -       (__clang_major__ == 3 && __clang_minor__ >= 4))) ||  -     (defined(__GNUC__) && __GNUC__ >= 5)) +       (__clang_major__ == 3 && __clang_minor__ >= 4)))) #include "base/numerics/safe_math_clang_gcc_impl.h" #define BASE_HAS_OPTIMIZED_SAFE_MATH (1) #else </del>  No newline at end of file

Discussion:
I try to install vivaldi-ffmpeg-codecs, it tries to build it — Just try to install vivaldi-ffmpeg-codecs. there was the same thing in previous 18.03.
I found that was removed in . Here it is in the : And the helpful thread:
I tried bluntly update the chromium source where codecs stored. But it failed:
That patch is marked .
Let's call submitter:
I tried bluntly update the chromium source where codecs stored. This is the right approach, but you'll also have to remove the old patches and check whether you need any newer . The patches used by the are usually a good starting point.
So unless I'm mistaken, shouldn't we just build chromium & provide a vivaldi output? The chromium build is huge & we don't want Hydra to have to do it multiple times. What's the intended use of ffmpeg-vivaldi-codecs? I think we can disable libcxx building with in args, though.
As i can see, there are some license issues (?) with something like h264. So we build in on "client" side from sources (probably it's x264)... I don't know exactly...
Providing a Vivaldi output from chromium (as suggests) is difficult because chromium moves at a different speed than Vivaldi, so the resulting library may not fit properly. I don't know how often this happens, but it looks like upstream ffmpeg changes their ABI fairly often. The build actually isn't that much of an issue. The only difficulty is having to download and extract the full chromium tarball, the compile times are short as we only need . What's the intended use of ffmpeg-vivaldi-codecs? Vivaldi (the company) cannot distribute certain codecs in ffmpeg in their packages, so we have to compile that separately.
Change:
<del> diff --git a/base/numerics/safe_math_shared_impl.h b/base/numerics/safe_math_shared_impl.h index 99f230ce7e9a..de2415d402f5 100644 --- a/base/numerics/safe_math_shared_impl.h +++ b/base/numerics/safe_math_shared_impl.h @@ -21,8 +21,7 @@ #if !defined(__native_client__) &&                          ((defined(__clang__) &&                                 ((__clang_major__ > 3) ||                             -       (__clang_major__ == 3 && __clang_minor__ >= 4))) ||  -     (defined(__GNUC__) && __GNUC__ >= 5)) +       (__clang_major__ == 3 && __clang_minor__ >= 4)))) #include "base/numerics/safe_math_clang_gcc_impl.h" #define BASE_HAS_OPTIMIZED_SAFE_MATH (1) #else </del>  No newline at end of file

Discussion:
This probably isn't a strictly NixOS issue, but nevertheless should be mentioned. The hash for vivaldi-stable2.1.1337.51-1 has changed. The old one in nixpkgs is 08x6abyz65vx4ycj8ys8sib9z1adb8ybmnrqjck69b30kbz78rj2, while nix-env reports 00rxp6rardxjg17g2b28y2rj8szqlainp4ga6c58z981zkxvdlls. to unstable channels. -env -i vivaldi system: host os: multi-user?: sandbox: version: channels(void): channels(root): nixpkgs:
unfortunately, sometimes software projects update different package sources with different sha256sums on their website, which will then error during build, until it gets fixed again Can you add a Pull Request, updating the hash in
Change:
stdenv.mkDerivation rec { pname = "tenacity"; <del> version = "1.3-beta2"; </del> <ins> version = "1.3.1"; </ins> src = fetchFromGitea { domain = "codeberg.org"; owner = "tenacityteam"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-9gWoqFa87neIvRnezWI3RyCAOU4wKEHPn/Hgj3/fol0="; </del> <ins> sha256 = "sha256-wesnay+UQiPSDaRuSo86MgHdElN4s0rPIvokZhKM7GI="; </ins> }; postPatch = ''

Discussion:
Package name: tenacity Latest released version: 1.3.1 <!-- Search your package here: --- Current version on the unstable channel: 1.3-beta2 Current version on the stable/release channel: 1.3-beta2 So, wanted to use tenacity because i'm not letting my grudge against muse go, sorry, when i noticed something odd: the version in nixpkgs is older than the latest release. appears there's no mechanism to alert maintainers of updates for this automatically so here's an issue i guess <!-- 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.
oh hey yep, that's me! thanks for the heads up, I'll get on that
(and I feel similarly about the whole audacity mess, it's why I packaged tenacity. I think this will be the first time there's been a proper stable tenacity release in nixpkgs, I'm looking forward to it.)
Change:
stdenv.mkDerivation rec { pname = "keepassxc"; <del> version = "2.5.4"; </del> <ins> version = "2.6.0"; </ins> src = fetchFromGitHub { owner = "keepassxreboot"; repo = "keepassxc"; rev = version; <del> sha256 = "1xih9q1pxszalc0l29fmjxwn1vrrrrbnhc8gmi8brw5sclhbs6bh"; </del> <ins> sha256 = "0yi6kxnsrqirjn6hxhwym2krzf86qxf3kc6bfpkmiaggnd2kqpkp"; </ins> }; NIX_CFLAGS_COMPILE = stdenv.lib.optionalString stdenv.cc.isClang [

Discussion:
Describe the bug program crash when clicking button To Reproduce Steps to reproduce the behavior: a database in keepassxc settings, secret service integration freedesktop integration edit database settings Expected behavior dialog open or something, no crash Screenshots ! Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
This is an . Workaround: Between steps 3 and 4, click "OK" and re-enter settings. You should then be able to edit the database settings.
Change:
}: rustPlatform.buildRustPackage rec { pname = "sequoia-wot"; <del> version = "0.11.0"; </del> <ins> version = "0.12.0"; </ins> src = fetchFromGitLab { owner = "sequoia-pgp"; repo = "sequoia-wot"; rev = "v${version}"; <del> hash = "sha256-qSf2uESsMGUEvAiRefpwxHKyizbq5Sst3SpjKaMIWTQ="; </del> <ins> hash = "sha256-Xbj1XLZQxyEYf/+R5e6EJMmL0C5ohfwZMZPVK5PwmUU="; </ins> }; <del> cargoHash = "sha256-vGseKdHqyncScS57UF3SR3EVdUGKVMue8fnRftefSY0="; </del> <ins> cargoHash = "sha256-BidSKnsIEEEU8UarbhqALcp44L0pes6O4m2mSEL1r4Q="; </ins> nativeBuildInputs = [ pkg-config

Discussion:
Steps to reproduce the behavior: Observed: Full checkPhase log (copied from Garnix): Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The checkPhase still fails with this PR applied, but it is a different error: Error: While creating /homeless- Caused by: Permission denied (os error 13)
Thanks for the report (I thought I rebuilt it successfully before I opened the PR). Now should be ready now (the failing test is skipped, and an upstream issue was created).
Change:
${removeReferencesTo}/bin/remove-references-to  -t ${stdenv.cc}  $out/lib/libruby* <ins> ${removeReferencesTo}/bin/remove-references-to  -t ${stdenv.cc}  $out/${passthru.libPath}/${stdenv.targetPlatform.system}/rbconfig.rb </ins> '' } # Bundler tries to create this directory

Discussion:
Describe the bug I'm hunting down packages that reference gcc. One of them is (maintainers: & ). Here's why: The fault is the fact that the build flag doesn't remove all references, as one might expect (EDIT, see: ). I'm up to including this feature, but I was wondering perhaps it'd be legit to disable this feature for the derivation? I opened a PR at (EDIT).
But that would mean gems that require a compiler would no longer work.
The suggestion is for , not . Isn't the derivation that's used to build the gems? According to:
It still has support for gems, so some will fail with gcc. What exactly is the use case for ?
Technically it's not used anywhere, according to .
I'd like to make my - with an overlay. The goal is to make the 1 or 2 pure ruby scripts I have on my system not pull , as they do today.
But what is the reason? You're likely to have a version of ruby that includes gcc on your system anyway, so you don't really save any space. And the use-case would be plain ruby scripts with only the gems that don't require system libraries. We have no users in nixpkgs of presumably because it's rather pointless. And while of course we can strip gcc from rubyMinimal (there's no harm), I'd rather say drop instead.
Not If I'll apply and this overlay: This allows me to not need GCC for for example - which is the only ruby gem I use. For example, run with this PR and that overlay applied: And you should get: And without , (and without the overlay because it would fail) you should get: is the only derivation that needs ruby that I actually use. I've updated the 1st comment in to exemplify this overlay as a possible usecase. Well I tend to agree - even for asciidoctor which should be pretty much a pure ruby gem, it still required and which aren't enabled in current . Hence I tend to agree. OK so I've updated to include a drop to , including release notes and an alias. Waiting for your review :crossed_fingers: .
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
]; propagatedBuildInputs = [ <del> mono54 </del> <ins> dotnet-sdk </ins> sqlite ]; preferLocalBuild = true; <del> # Need to set sourceRoot as unpacker will complain about multiple directory output sourceRoot = "."; </del> buildPhase = '' <del> substituteInPlace SQLitePCLRaw.provider.sqlite3.dll.config --replace libsqlite3.so ${sqlite.out}/lib/libsqlite3.so substituteInPlace MediaBrowser.Server.Mono.exe.config --replace ProgramData-Server "/var/lib/emby/ProgramData-Server" </del> <ins> rm -rf {electron,runtimes} </ins> ''; installPhase = '' <del> mkdir -p "$out/bin" cp -r * "$out/bin" makeWrapper "${mono54}/bin/mono" $out/bin/MediaBrowser.Server.Mono  --add-flags "$out/bin/MediaBrowser.Server.Mono.exe -ffmpeg ${ffmpeg}/bin/ffmpeg -ffprobe ${ffmpeg}/bin/ffprobe" </del> <ins> install -dm 755 "$out/opt/emby-server" cp -r * "$out/opt/emby-server" makeWrapper "${dotnet-sdk}/bin/dotnet" $out/bin/emby  --prefix LD_LIBRARY_PATH : "${stdenv.lib.makeLibraryPath [ sqlite ]}"  --add-flags "$out/opt/emby-server/EmbyServer.dll -programdata /var/lib/emby/ProgramData-Server -ffmpeg ${ffmpeg}/bin/ffmpeg -ffprobe ${ffmpeg}/bin/ffprobe" </ins> ''; meta =  with stdenv.lib; {

Discussion:
The latest version of Emby is only available in the dotnet core version : I can't find any documentation on how to package a dotnet app in NixOS. Help would be much appreciated ! I found that the dotnet-sdk package is providing the dotnet executable, is it a simple swap between mono and this ?
I am interested in using dotnet with nixpkgs. The dotnet-sdk is up to date and can build and run applications but there is also , which is just the runtime. It might be a good practice to use dotnet-sdk for building but build the wrapper with coreclr. This should result in smaller runtime closures. There is also which is actually using mono.
Change:
dontUseSetuptoolsCheck = true; <ins> patches = [ # dask dataframe cannot be imported in sandboxed builds # See https://github.com/dask/dask/pull/7601 (fetchpatch { url = "https://github.com/dask/dask/commit/9ce5b0d258cecb3ef38fd844135ad1f7ac3cea5f.patch"; sha256 = "sha256-1EVRYwAdTSEEH9jp+UOnrijzezZN3iYR6q6ieYJM3kY="; name = "fix-dask-dataframe-imports-in-sandbox.patch"; }) ]; </ins> postPatch = '' # versioneer hack to set version of github package echo "def get_versions(): return {'dirty': False, 'error': None, 'full-revisionid': None, 'version': '${version}'}" > dask/_version.py

Discussion:
Describe the bug For sandboxed builds on my mac, any python tests which ultimately import will fail with this error: To Reproduce Somewhat tricky to reproduce since it only affects downstream dependees, and a recent commit disabled the dask tests, hiding this issue. See for an example. Additional context Dask.dataframes infers an optimal chunk size using a package to get the amount of available memory and CPUs. This non-determinism breaks the build. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc Metadata This is not valid since I am building from master of nixpkgs. system: host os: multi-user?: sandbox: version: channels(noah): nixpkgs: Maintainer information:
That's a clear upstream bug; apparently their value is not given.
Change:
python-packer = callPackage ../development/python-modules/python-packer { }; <del> python-pam = callPackage ../development/python-modules/python-pam { }; </del> <ins> python-pam = callPackage ../development/python-modules/python-pam { inherit (pkgs) pam; }; </ins> python-periphery = callPackage ../development/python-modules/python-periphery { };

Discussion:
Describe the bug , which provides the "pam" namespace to everything in python-packages. This is fine, except this also broke the definition of , which packages the same library at the same version. To Reproduce Steps to reproduce the behavior: build result/lib/python3.8/site- points at a non-existent SO in the "pam" Python package Expected behavior Only one, working definition of this Python package. Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
The problem is that the python-pam probably is referencing the pam python package from the current scope, which I solved in my package by inheriting from the parent scope. The reason why pam was created in the first place is because I got confused because of the name and I imagine the reason it was named python-pam by the original author is to solve the inherit issue in another way, namely renaming it. I'd be in favour of the name "pam" because that's how the module is being called (unless both modules do have differences, then we need both)
I'm not particularly fussed about which one "wins", just that we should probably only have one of them. I agree that "pam" is probably a better name - it's just a little unergonomic to use in the tree.
Thanks for reporting. See
Change:
bypassCache = true; reconstructLock = true; }; <del> "@withgraphite/graphite-cli" = nodeEnv.buildNodePackage { name = "_at_withgraphite_slash_graphite-cli"; packageName = "@withgraphite/graphite-cli"; version = "1.0.14"; src = fetchurl { url = "https://registry.npmjs.org/@withgraphite/graphite-cli/-/graphite-cli-1.0.14.tgz"; sha512 = "VXgUM5RSYXMVc9i3E1A6j0CYNS5ScQjUXaKO9l3epOws5rxiyDa7QOl7tiSXTQw1eQKtzXxiwve+iWDZsPSDQw=="; }; dependencies = [ sources."ansi-regex-5.0.1" sources."ansi-styles-4.3.0" sources."bufferutil-4.0.8" sources."chalk-4.1.2" sources."cliui-8.0.1" sources."color-convert-2.0.1" sources."color-name-1.1.4" sources."emoji-regex-8.0.0" sources."escalade-3.1.1" sources."get-caller-file-2.0.5" sources."has-flag-4.0.0" sources."is-fullwidth-code-point-3.0.0" sources."node-gyp-build-4.8.0" sources."require-directory-2.1.1" sources."string-width-4.2.3" sources."strip-ansi-6.0.1" sources."supports-color-7.2.0" sources."utf-8-validate-6.0.3" sources."wrap-ansi-7.0.0" sources."ws-8.16.0" sources."y18n-5.0.8" sources."yargs-17.7.2" sources."yargs-parser-21.1.1" ]; buildInputs = globalBuildInputs; meta = { homepage = "https://github.com/withgraphite/graphite-cli"; license = "None"; }; production = true; bypassCache = true; reconstructLock = true; }; </del> wrangler = nodeEnv.buildNodePackage { name = "wrangler"; packageName = "wrangler";

Discussion:
Package name: Grahpite-cli Latest released version: 1.1.1 <!-- Search your package here: --- Current version on the unstable channel: 1.0.9 Current version on the stable/release channel: 1.0.9 <!-- 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. This package has no maintainer because it is a NPM package. might be related? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hello thanks for the request, I will try to go from node2nix to build from source as the issue linked suggestes
Giving a quick check to the graphite-cli repo linked in the npm package it is archived and "moved to your mono-repo" and also it is built with yarn so nor it can migrated to buildNpmPackage nor to building from source, so my guess is that it will need to still in node2nix
Please make a PR marking the package as unfree since their monorepo isn't publicly available.
As of right now graphite-cli is already unfree
Change:
extraBuildFlags+=(--option "build-users-group" "$buildUsersGroup") # Inherit binary caches from the host <del> # TODO: will this still work with Nix 1.12 now that it has no perl? Probably not... </del> <ins> # TODO: will this still work with Nix 1.12 now that it has no perl? Probably not... </ins> binary_caches="$(@perl@/bin/perl -I @nix@/lib/perl5/site_perl/*/* -e 'use Nix::Config; Nix::Config::readConfig; print $Nix::Config::config{"binary-caches"};')" extraBuildFlags+=(--option "binary-caches" "$binary_caches")

Discussion:
the runChroot code in nixos-install was removed in it will now try to do a full install if you run cc
I'll try to restore before 17.09 branch point, sorry!
Okay I'm looking at this now. I'm not entirely clear on the flag's purpose, so it's hard for me to add it back (even looking at the old code), and it doesn't really appear to be documented except that it gets mentioned in the manual once in passing. Can someone elaborate on what it's for and what it's guarding against? That'll make it much easier for me to add it back. Edit: the commit message clarifies some of it. I guess it's chroot + some bind mounts to make the chroot usable? It feels a little odd to stick that under but I guess I should replicate that behavior.
Okay, I get what it's supposed to do. is just "set up a few bind mounts like /proc to make it look legit, and then chroot", right? It has nothing to do with installation except that one might want to use it to test a fresh install (but one might also want to use it to test an unfresh install mounted on another machine, or something).
Also useful to fix a broken installation, e.g. when you broke your boot loader or something similar severe. Then you can boot from usb, run and then do a rebuild, and everything works again.
Cool! do you have a good test setup for my PR addressing this? My access to physical NixOS boxes for testing is limited right now.
the hardware's here, but did not manage to get your PR version running on my NixOS live usb key to try it, or somehow mount a snapshot of my actual installation and trick nixos-install into chrooting into that.
Note that on Arch Linux, and are two separate tools, and , which would at least make it easier to test this skipping all that mount point checking, as well as more flexible. And it would also prevent the confusion on what does in the first place.
ping We only have a few days left until the release. :)
I've updated the PR, sorry!