jiebi/CodeConvo huggingface dataset:
Code change:
Describe the bug By default and according to bazel documentation (), bazel is looking for a system-wide configuration is . In I decided to override this path and make it point in . It was the easiest solution to pass arguments to bazel in order to fix a few runtime issues. However it breaks the assumption that user can configure bazel using . To Reproduce Use bazel from nixpkgs with . Set some bazel settings in your file Observe that bazel ignores this file Expected behavior I'm opening this bug report to discuss what should be the expected behavior here? Should we respect the ? If yes, I'll open a pull request to restore the previous behavior.
I'll be in favour of keeping support for all paths specified in the documentation - having a system-wide is something people might want to make use of, so we shouldn't take away that possibility. We currently set the following options in bazelrc: We should either patch these as defaults into nixos, or introduce reading from a distro-provided location (should be coordinated with bazel upstream). I think adding a wrapper is a bit too much for all these options.
I do agree with your point of view. I'll try to propose a PR which restore the old behavior. In the meantime, I'm open to other comments on this issue. Regarding the options you quote, they are used in a local during build only. The global bazelrc that I provide is way simpler: Both were ad hoc solution for different problems, respectively issue and commit .

Related discussion:
text: , autoPatchelfHook , file , substituteAll <ins> , writeTextFile </ins> }: let
Code change:
Describe the bug By default and according to bazel documentation (), bazel is looking for a system-wide configuration is . In I decided to override this path and make it point in . It was the easiest solution to pass arguments to bazel in order to fix a few runtime issues. However it breaks the assumption that user can configure bazel using . To Reproduce Use bazel from nixpkgs with . Set some bazel settings in your file Observe that bazel ignores this file Expected behavior I'm opening this bug report to discuss what should be the expected behavior here? Should we respect the ? If yes, I'll open a pull request to restore the previous behavior.
I'll be in favour of keeping support for all paths specified in the documentation - having a system-wide is something people might want to make use of, so we shouldn't take away that possibility. We currently set the following options in bazelrc: We should either patch these as defaults into nixos, or introduce reading from a distro-provided location (should be coordinated with bazel upstream). I think adding a wrapper is a bit too much for all these options.
I do agree with your point of view. I'll try to propose a PR which restore the old behavior. In the meantime, I'm open to other comments on this issue. Regarding the options you quote, they are used in a local during build only. The global bazelrc that I provide is way simpler: Both were ad hoc solution for different problems, respectively issue and commit .

Related discussion:
text: ''; }; <ins> bazelRC = writeTextFile { name = "bazel-rc"; text = '' build --override_repository=${remote_java_tools.name}=${remote_java_tools} build --distdir=${distDir} startup --server_javabase=${runJdk} # load default location for the system wide configuration try-import /etc/bazel.bazelrc ''; }; </ins> in stdenv.mkDerivation rec { pname = "bazel";
Code change:
Describe the bug By default and according to bazel documentation (), bazel is looking for a system-wide configuration is . In I decided to override this path and make it point in . It was the easiest solution to pass arguments to bazel in order to fix a few runtime issues. However it breaks the assumption that user can configure bazel using . To Reproduce Use bazel from nixpkgs with . Set some bazel settings in your file Observe that bazel ignores this file Expected behavior I'm opening this bug report to discuss what should be the expected behavior here? Should we respect the ? If yes, I'll open a pull request to restore the previous behavior.
I'll be in favour of keeping support for all paths specified in the documentation - having a system-wide is something people might want to make use of, so we shouldn't take away that possibility. We currently set the following options in bazelrc: We should either patch these as defaults into nixos, or introduce reading from a distro-provided location (should be coordinated with bazel upstream). I think adding a wrapper is a bit too much for all these options.
I do agree with your point of view. I'll try to propose a PR which restore the old behavior. In the meantime, I'm open to other comments on this issue. Regarding the options you quote, they are used in a local during build only. The global bazelrc that I provide is way simpler: Both were ad hoc solution for different problems, respectively issue and commit .

Related discussion:
text: src = ./strict_action_env.patch; strictActionEnvPatch = defaultShellPath; }) <ins> # bazel reads its system bazelrc in /etc # override this path to a builtin one (substituteAll { src = ./bazel_rc.patch; bazelSystemBazelRCPath = bazelRC; }) </ins> ] ++ lib.optional enableNixHacks ./nix-hacks.patch;
Code change:
Describe the bug By default and according to bazel documentation (), bazel is looking for a system-wide configuration is . In I decided to override this path and make it point in . It was the easiest solution to pass arguments to bazel in order to fix a few runtime issues. However it breaks the assumption that user can configure bazel using . To Reproduce Use bazel from nixpkgs with . Set some bazel settings in your file Observe that bazel ignores this file Expected behavior I'm opening this bug report to discuss what should be the expected behavior here? Should we respect the ? If yes, I'll open a pull request to restore the previous behavior.
I'll be in favour of keeping support for all paths specified in the documentation - having a system-wide is something people might want to make use of, so we shouldn't take away that possibility. We currently set the following options in bazelrc: We should either patch these as defaults into nixos, or introduce reading from a distro-provided location (should be coordinated with bazel upstream). I think adding a wrapper is a bit too much for all these options.
I do agree with your point of view. I'll try to propose a PR which restore the old behavior. In the meantime, I'm open to other comments on this issue. Regarding the options you quote, they are used in a local during build only. The global bazelrc that I provide is way simpler: Both were ad hoc solution for different problems, respectively issue and commit .

Related discussion:
text: mv runfiles.bash.tmp tools/bash/runfiles/runfiles.bash patchShebangs . <del> # bazel reads its system bazelrc in /etc # override this path to a builtin one substituteInPlace  src/main/cpp/option_processor.cc  --replace BAZEL_SYSTEM_BAZELRC_PATH ""$out/etc/bazelrc"" </del> ''; in lib.optionalString stdenv.hostPlatform.isDarwin darwinPatches + genericPatches;
Code change:
Describe the bug By default and according to bazel documentation (), bazel is looking for a system-wide configuration is . In I decided to override this path and make it point in . It was the easiest solution to pass arguments to bazel in order to fix a few runtime issues. However it breaks the assumption that user can configure bazel using . To Reproduce Use bazel from nixpkgs with . Set some bazel settings in your file Observe that bazel ignores this file Expected behavior I'm opening this bug report to discuss what should be the expected behavior here? Should we respect the ? If yes, I'll open a pull request to restore the previous behavior.
I'll be in favour of keeping support for all paths specified in the documentation - having a system-wide is something people might want to make use of, so we shouldn't take away that possibility. We currently set the following options in bazelrc: We should either patch these as defaults into nixos, or introduce reading from a distro-provided location (should be coordinated with bazel upstream). I think adding a wrapper is a bit too much for all these options.
I do agree with your point of view. I'll try to propose a PR which restore the old behavior. In the meantime, I'm open to other comments on this issue. Regarding the options you quote, they are used in a local during build only. The global bazelrc that I provide is way simpler: Both were ad hoc solution for different problems, respectively issue and commit .

Related discussion:
text: cp ./bazel_src/scripts/packages/bazel.sh $out/bin/bazel mv ./bazel_src/output/bazel $out/bin/bazel-real <del> wrapProgram "$out/bin/bazel" --add-flags --server_javabase="${runJdk}" # generates the system bazelrc # warning: the name of the repository depends on the system, hence # the reference to .name mkdir $out/etc echo "build --override_repository=${remote_java_tools.name}=${remote_java_tools}" > $out/etc/bazelrc echo "build --distdir=${distDir}" >> $out/etc/bazelrc </del> # shell completion files mkdir -p $out/share/bash-completion/completions $out/share/zsh/site-functions mv ./bazel_src/output/bazel-complete.bash $out/share/bash-completion/completions/bazel
Code change:
Capability wrappers are somewhat limited. They require the capability be part of the ambient set for it to survive execv's, ie. when the wrapper executes the source binary (). This means any program spawned from a wrapped binary will also inherit the capabilities. We really don't want programs launched from gnome-shell to inherit capsysnice obviously. In particular bubblewrap fails to work if it possess any extra caps, breaking at least flatpaks and epiphany. So as far as I can see we have two options: Actually copy to wrapperDir and set capsysnic=+ep. This should be pretty easy, but also quite ugly (see for context). Patch mutter to drop inheritable, we could probably adopt . This should probably work as the ambient set only propagates if inheritable is set. cc
Patching mutter to drop inheritable works :tada:, will make a PR :)
Does the rationale for not merging it not apply to us?
No it shouldn't. We only drop inheritable to prevent the ambient set being passed on, while keeping effective and permitted for gnome-shell. (it might be possible to drop the ambient set with , but I went with just clearing inheritable):

Related discussion:
text: source-sans-pro ]; <ins> ## Enable soft realtime scheduling, only supported on wayland ## security.wrappers.".gnome-shell-wrapped" = { source = "${pkgs.gnome3.gnome-shell}/bin/.gnome-shell-wrapped"; capabilities = "cap_sys_nice=ep"; }; systemd.user.services.gnome-shell-wayland = let gnomeShellRT = with pkgs.gnome3; pkgs.runCommand "gnome-shell-rt" {} '' mkdir -p $out/bin/ cp ${gnome-shell}/bin/gnome-shell $out/bin sed -i "s@${gnome-shell}/bin/@${config.security.wrapperDir}/@" $out/bin/gnome-shell ''; in { # Note we need to clear ExecStart before overriding it serviceConfig.ExecStart = ["" "${gnomeShellRT}/bin/gnome-shell"]; # Do not use the default environment, it provides a broken PATH environment = mkForce {}; }; </ins> # Adapt from https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/gnome-3-32/elements/core/meta-gnome-core-shell.bst environment.systemPackages = with pkgs.gnome3; [ adwaita-icon-theme
Code change:
Capability wrappers are somewhat limited. They require the capability be part of the ambient set for it to survive execv's, ie. when the wrapper executes the source binary (). This means any program spawned from a wrapped binary will also inherit the capabilities. We really don't want programs launched from gnome-shell to inherit capsysnice obviously. In particular bubblewrap fails to work if it possess any extra caps, breaking at least flatpaks and epiphany. So as far as I can see we have two options: Actually copy to wrapperDir and set capsysnic=+ep. This should be pretty easy, but also quite ugly (see for context). Patch mutter to drop inheritable, we could probably adopt . This should probably work as the ambient set only propagates if inheritable is set. cc
Patching mutter to drop inheritable works :tada:, will make a PR :)
Does the rationale for not merging it not apply to us?
No it shouldn't. We only drop inheritable to prevent the ambient set being passed on, while keeping effective and permitted for gnome-shell. (it might be possible to drop the ambient set with , but I went with just clearing inheritable):

Related discussion:
text: { fetchurl, fetchpatch, substituteAll, stdenv, pkgconfig, gnome3, gettext, gobject-introspection, upower, cairo <del> , pango, cogl, clutter, libstartup_notification, zenity, libcanberra-gtk3 </del> <ins> , pango, cogl, json-glib, libstartup_notification, zenity, libcanberra-gtk3 </ins> , ninja, xkeyboard_config, libxkbfile, libxkbcommon, libXtst, libinput , gsettings-desktop-schemas, glib, gtk3, gnome-desktop , geocode-glib, pipewire, libgudev, libwacom, xwayland, meson
Code change:
Capability wrappers are somewhat limited. They require the capability be part of the ambient set for it to survive execv's, ie. when the wrapper executes the source binary (). This means any program spawned from a wrapped binary will also inherit the capabilities. We really don't want programs launched from gnome-shell to inherit capsysnice obviously. In particular bubblewrap fails to work if it possess any extra caps, breaking at least flatpaks and epiphany. So as far as I can see we have two options: Actually copy to wrapperDir and set capsysnic=+ep. This should be pretty easy, but also quite ugly (see for context). Patch mutter to drop inheritable, we could probably adopt . This should probably work as the ambient set only propagates if inheritable is set. cc
Patching mutter to drop inheritable works :tada:, will make a PR :)
Does the rationale for not merging it not apply to us?
No it shouldn't. We only drop inheritable to prevent the ambient set being passed on, while keeping effective and permitted for gnome-shell. (it might be possible to drop the ambient set with , but I went with just clearing inheritable):

Related discussion:
text: , wrapGAppsHook , sysprof , desktop-file-utils <ins> , libcap_ng </ins> }: stdenv.mkDerivation rec {
Code change:
Capability wrappers are somewhat limited. They require the capability be part of the ambient set for it to survive execv's, ie. when the wrapper executes the source binary (). This means any program spawned from a wrapped binary will also inherit the capabilities. We really don't want programs launched from gnome-shell to inherit capsysnice obviously. In particular bubblewrap fails to work if it possess any extra caps, breaking at least flatpaks and epiphany. So as far as I can see we have two options: Actually copy to wrapperDir and set capsysnic=+ep. This should be pretty easy, but also quite ugly (see for context). Patch mutter to drop inheritable, we could probably adopt . This should probably work as the ambient set only propagates if inheritable is set. cc
Patching mutter to drop inheritable works :tada:, will make a PR :)
Does the rationale for not merging it not apply to us?
No it shouldn't. We only drop inheritable to prevent the ambient set being passed on, while keeping effective and permitted for gnome-shell. (it might be possible to drop the ambient set with , but I went with just clearing inheritable):

Related discussion:
text: propagatedBuildInputs = [ # required for pkgconfig to detect mutter-clutter libXtst <ins> json-glib libcap_ng </ins> ]; nativeBuildInputs = [
Code change:
Capability wrappers are somewhat limited. They require the capability be part of the ambient set for it to survive execv's, ie. when the wrapper executes the source binary (). This means any program spawned from a wrapped binary will also inherit the capabilities. We really don't want programs launched from gnome-shell to inherit capsysnice obviously. In particular bubblewrap fails to work if it possess any extra caps, breaking at least flatpaks and epiphany. So as far as I can see we have two options: Actually copy to wrapperDir and set capsysnic=+ep. This should be pretty easy, but also quite ugly (see for context). Patch mutter to drop inheritable, we could probably adopt . This should probably work as the ambient set only propagates if inheritable is set. cc
Patching mutter to drop inheritable works :tada:, will make a PR :)
Does the rationale for not merging it not apply to us?
No it shouldn't. We only drop inheritable to prevent the ambient set being passed on, while keeping effective and permitted for gnome-shell. (it might be possible to drop the ambient set with , but I went with just clearing inheritable):

Related discussion:
text: buildInputs = [ glib gobject-introspection gtk3 gsettings-desktop-schemas upower <del> gnome-desktop cairo pango cogl clutter zenity libstartup_notification </del> <ins> gnome-desktop cairo pango cogl zenity libstartup_notification </ins> geocode-glib libinput libgudev libwacom libcanberra-gtk3 zenity xkeyboard_config libxkbfile libxkbcommon pipewire xwayland
Code change:
Capability wrappers are somewhat limited. They require the capability be part of the ambient set for it to survive execv's, ie. when the wrapper executes the source binary (). This means any program spawned from a wrapped binary will also inherit the capabilities. We really don't want programs launched from gnome-shell to inherit capsysnice obviously. In particular bubblewrap fails to work if it possess any extra caps, breaking at least flatpaks and epiphany. So as far as I can see we have two options: Actually copy to wrapperDir and set capsysnic=+ep. This should be pretty easy, but also quite ugly (see for context). Patch mutter to drop inheritable, we could probably adopt . This should probably work as the ambient set only propagates if inheritable is set. cc
Patching mutter to drop inheritable works :tada:, will make a PR :)
Does the rationale for not merging it not apply to us?
No it shouldn't. We only drop inheritable to prevent the ambient set being passed on, while keeping effective and permitted for gnome-shell. (it might be possible to drop the ambient set with , but I went with just clearing inheritable):

Related discussion:
text: ]; patches = [ <ins> # Drop inheritable cap_sys_nice, to prevent the ambient set from leaking # from mutter/gnome-shell, see https://github.com/NixOS/nixpkgs/issues/71381 ./drop-inheritable.patch </ins> # TODO: submit upstream ./0001-build-use-get_pkgconfig_variable-for-sysprof-dbusdir.patch (substituteAll {
Code change:
on Hydra: cc
Since it's been building for me, checked if I was sitting on any changes and while the commit message doesn't indicate that it fixes anything (eep), it does seem to fix this issue: Don't remember enough details to justify it fully offhand (again d'oh for not writing it down at the time hehe) but hopefully this helps work towards a suitable resolution :).
Naturally this breaks in as well.
Yep, broken for me too. Haven't had time to tinker yet.
I have the same problem, but the commit mentioned fixes it for me.
So are we just waiting for this commit to be in the unstable channels?

Related discussion:
text: <del> { mkDerivation, lib, fetchurl, qtbase, qttools, qmake }: </del> <ins> { mkDerivation, lib, fetchurl, qtbase, qtsvg, qttools, qmake }: </ins> let inherit (lib) getDev; in
Code change:
on Hydra: cc
Since it's been building for me, checked if I was sitting on any changes and while the commit message doesn't indicate that it fixes anything (eep), it does seem to fix this issue: Don't remember enough details to justify it fully offhand (again d'oh for not writing it down at the time hehe) but hopefully this helps work towards a suitable resolution :).
Naturally this breaks in as well.
Yep, broken for me too. Haven't had time to tinker yet.
I have the same problem, but the commit mentioned fixes it for me.
So are we just waiting for this commit to be in the unstable channels?

Related discussion:
text: nativeBuildInputs = [ qmake qttools ]; <del> buildInputs = [ qtbase ]; </del> <ins> buildInputs = [ qtbase qtsvg ]; </ins> qmakeFlags = [ "LRELEASE_EXECUTABLE=${getDev qttools}/bin/lrelease" <ins> "PLUGINDIR=${placeholder "out"}/${qtbase.qtPluginPrefix}" </ins> ]; <del> preConfigure = '' qmakeFlags+=" PLUGINDIR=$out/$qtPluginPrefix" ''; </del> enableParallelBuilding = true; meta = with lib; {
Code change:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency. The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.

Related discussion:
text: { stdenv , fetchFromGitHub <ins> , fetchpatch </ins> , cairo , graphicsmagick , pkg-config