Question:
Using with seems to be broken with and . It fails with . also notes this. Running yields . The contains just an empty and I am using this flake's devShell: The same also occurs when using a shell with only and when trying to use inside a nix build. I am pretty sure that this is caused by in containing instead of (which it does for ). I don't know yet, what the root cause for that is or how to fix that. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (So it shows up in the tracking issue )
Apologies for the delay in getting to this. Minimizing your example ultimately leaves me with: Staring at the output of ^ with reveals that is a linker script that appears to be passing in : For LLVM 14 this file looks like: But for LLVM 15: EDIT: whoops, my bad; just noticed that you already mentioned this in your post, I totally missed it Looking through the source, this file appears to be generated ; specifically the should be coming from based on . For Linux/macOS (i.e. platforms using libc++-abi) that should be set . Poking around a bit suggests that this is a bug in upstream; is not an interface library so it has no (though it has an ) and its is never set. And sure enough, looking at upstream reveals that has been (see ).
Applying that patch and rebuilding locally seems to fix the issue; I'll open a PR (and add regression tests for this) shortly.
Thanks for looking into this! Building from the PR-branch now no longer fails in the way I described and the example works for me again. I have now found a new issue, tho: Importing fails with: For example, this causes this error (using the same flake as above, just built from the PR branch). I was able to work around this, by adding to the end of the phase of locally, but I am not sure if that's the right approach here.
(Re I have a proposed fix for the _cxxabiconfig.h issue on llvmPackages_16: -- currently I'm inserting an additional include search dir for it. I also don't know if this is the best approach or alternatively if that header (and friends?) should be copied into libcxx or similar.
I ran into the same missing header issue compiling using on . Maybe the fix isn't enough, and should be copied?
this change is missing from 15
running into the same problem compiling some static libraries in nixpkgs using pkgs.llvmPackages_16.libcxxStdenv. Does this warrant its own issue?
Yes, file a new issue. Please also provide reproducibility bits, including the error message you see, the package expression you're trying to build, and the nixpkgs revision. I'm guessing the issue you're seeing is failing to build, which is a different problem specific to static builds.
(If my guess is accurate, the problem you're seeing is a variant of ).
sorry for bothering you, turns out it wasn't really this issue. Using my limited knowledge on the matter from what I understand, is not installed to like . Now, turns out (and ) is a default system header path (for CXX of course) and so is BUT is not so if one were to they would just run into since that is nowhere to be found. There are two solutions to this is as a system header path like we simply just install everything under on non darwin systems as well. I actually do not know why these are all not copied on non darwin systems. Please correct me if wrong. I might be completely wrong.
check
No bother. I'm sticking my oar in because I'm interested in getting to the bottom of issues exactly like this. It's difficult to fix things it without precise reproduction steps, though. What you're describing there sounds very much like something I tried to address in (see ), which is on nixos-unstable. So it sounds like you may have found further issues, but I can't do much to help without a reproducer. In any case what you're describing sounds like a different issue to the original (which was ), so I suggest posting a new issue pretty much as you described but with a reproducer I can run at the terminal, since it is meant to be in the system include path already (per the link above). If it's not, that sounds like a bug worth filing.
Okay I found the problem, and the "obvious" solution as well, you can find it here

patches = [ ./gnu-install-dirs.patch <ins> # See: #   - https://reviews.llvm.org/D133566 #   - https://github.com/NixOS/nixpkgs/issues/214524#issuecomment-1429146432 # !!! Drop in LLVM 16+ (fetchpatch { url = "https://github.com/llvm/llvm-project/commit/57c7bb3ec89565c68f858d316504668f9d214d59.patch"; hash = "sha256-AaM9A6tQ4YAw7uDqCIV4VaiUyLZv+unwcOqbakwW9/k="; relative = "libcxx"; }) </ins> ] ++ lib.optionals stdenv.hostPlatform.isMusl [ ../../libcxx-0001-musl-hacks.patch ];


Question:
Using with seems to be broken with and . It fails with . also notes this. Running yields . The contains just an empty and I am using this flake's devShell: The same also occurs when using a shell with only and when trying to use inside a nix build. I am pretty sure that this is caused by in containing instead of (which it does for ). I don't know yet, what the root cause for that is or how to fix that. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (So it shows up in the tracking issue )
Apologies for the delay in getting to this. Minimizing your example ultimately leaves me with: Staring at the output of ^ with reveals that is a linker script that appears to be passing in : For LLVM 14 this file looks like: But for LLVM 15: EDIT: whoops, my bad; just noticed that you already mentioned this in your post, I totally missed it Looking through the source, this file appears to be generated ; specifically the should be coming from based on . For Linux/macOS (i.e. platforms using libc++-abi) that should be set . Poking around a bit suggests that this is a bug in upstream; is not an interface library so it has no (though it has an ) and its is never set. And sure enough, looking at upstream reveals that has been (see ).
Applying that patch and rebuilding locally seems to fix the issue; I'll open a PR (and add regression tests for this) shortly.
Thanks for looking into this! Building from the PR-branch now no longer fails in the way I described and the example works for me again. I have now found a new issue, tho: Importing fails with: For example, this causes this error (using the same flake as above, just built from the PR branch). I was able to work around this, by adding to the end of the phase of locally, but I am not sure if that's the right approach here.
(Re I have a proposed fix for the _cxxabiconfig.h issue on llvmPackages_16: -- currently I'm inserting an additional include search dir for it. I also don't know if this is the best approach or alternatively if that header (and friends?) should be copied into libcxx or similar.
I ran into the same missing header issue compiling using on . Maybe the fix isn't enough, and should be copied?
this change is missing from 15
running into the same problem compiling some static libraries in nixpkgs using pkgs.llvmPackages_16.libcxxStdenv. Does this warrant its own issue?
Yes, file a new issue. Please also provide reproducibility bits, including the error message you see, the package expression you're trying to build, and the nixpkgs revision. I'm guessing the issue you're seeing is failing to build, which is a different problem specific to static builds.
(If my guess is accurate, the problem you're seeing is a variant of ).
sorry for bothering you, turns out it wasn't really this issue. Using my limited knowledge on the matter from what I understand, is not installed to like . Now, turns out (and ) is a default system header path (for CXX of course) and so is BUT is not so if one were to they would just run into since that is nowhere to be found. There are two solutions to this is as a system header path like we simply just install everything under on non darwin systems as well. I actually do not know why these are all not copied on non darwin systems. Please correct me if wrong. I might be completely wrong.
check
No bother. I'm sticking my oar in because I'm interested in getting to the bottom of issues exactly like this. It's difficult to fix things it without precise reproduction steps, though. What you're describing there sounds very much like something I tried to address in (see ), which is on nixos-unstable. So it sounds like you may have found further issues, but I can't do much to help without a reproducer. In any case what you're describing sounds like a different issue to the original (which was ), so I suggest posting a new issue pretty much as you described but with a reproducer I can run at the terminal, since it is meant to be in the system include path already (per the link above). If it's not, that sounds like a bug worth filing.
Okay I found the problem, and the "obvious" solution as well, you can find it here

# libcxxStdenv broken # fix in https://github.com/NixOS/nixpkgs/pull/216273 <del> (filter (n: n != "llvmPackages_15")) </del> ] ++ lib.optionals (stdenv.hostPlatform.isLinux && stdenv.hostPlatform.isAarch64) [ # libcxx does not build for some reason on aarch64-linux (filter (n: n != "llvmPackages_7"))


Question:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...

, cython , dill , fastavro <ins> , fasteners </ins> , fetchFromGitHub , fetchpatch , freezegun


Question:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...

, grpcio-tools , hdfs , httplib2 <ins> , hypothesis </ins> , lib , mock , mypy-protobuf , numpy <del> , oauth2client </del> <ins> , objsize </ins> , orjson , pandas , parameterized


Question:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...

, pydot , pyhamcrest , pymongo <ins> , pytest-xdist </ins> , pytestCheckHook , python , python-dateutil <del> , pythonAtLeast </del> , pythonRelaxDepsHook , pytz , pyyaml <ins> , regex </ins> , requests , requests-mock , scikit-learn <del> , setuptools </del> , sqlalchemy , tenacity , testcontainers , typing-extensions <ins> , zstandard </ins> }: buildPythonPackage rec { pname = "apache-beam"; <del> version = "2.43.0"; </del> <ins> version = "2.44.0"; </ins> src = fetchFromGitHub { owner = "apache"; repo = "beam"; rev = "refs/tags/v${version}"; <del> sha256 = "sha256-lqGXCC66eyBnHcK06k9knggX5C+2d0m6xBAI5sh0RHo="; </del> <ins> hash = "sha256-5fnZxv2ZkFlv8vGDIt/6EL41v9P1iKa1tEd1nezq+PU="; </ins> }; patches = [


Question:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...

hash = "sha256-iUmnzrItTFM98w3mpadzrmtI3t0fucpSujAg/6qxCGk="; stripLen = 2; }) <del> (fetchpatch { # https://github.com/apache/beam/pull/24573 name = "relax-httplib2-version.patch"; url = "https://github.com/apache/beam/commit/4045503575ae5ccef3de8d7b868c54e37fef658b.patch"; hash = "sha256-YqT+sHaa1R9vLQnEQN2K0lYoCdnGoPY9qduGBpXPaek="; stripLen = 2; }) </del> ]; pythonRelaxDeps = [ # See https://github.com/NixOS/nixpkgs/issues/156957 "dill" "numpy" <del> "pyarrow" </del> "pymongo" # See https://github.com/NixOS/nixpkgs/issues/193613 "protobuf" <ins> # As of apache-beam v2.44.0, the requirement is httplib2>=0.8,<0.21.0, but # the current (2023-02-08) nixpkgs's httplib2 version is 0.21.0. This can be # removed once beam is upgraded since the current requirement on master is # for httplib2>=0.8,<0.22.0. "httplib2" </ins> ]; sourceRoot = "source/sdks/python";


Question:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...

propagatedBuildInputs = [ cloudpickle crcmod <del> cython </del> dill fastavro <ins> fasteners </ins> grpcio hdfs httplib2 numpy <del> oauth2client </del> <ins> objsize </ins> orjson proto-plus protobuf


Question:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...

pymongo python-dateutil pytz <ins> regex </ins> requests <del> setuptools </del> typing-extensions <ins> zstandard </ins> ]; enableParallelBuilding = true;


Question:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...

"apache_beam" ]; <del> nativeCheckInputs = [ </del> <ins> checkInputs = [ </ins> freezegun <ins> hypothesis </ins> mock pandas parameterized psycopg2 pyhamcrest pytestCheckHook <ins> pytest-xdist </ins> pyyaml requests-mock scikit-learn


Question:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...

# Fails starting from dill 0.3.6 because it tries to pickle pytest globals: # https://github.com/uqfoundation/dill/issues/482#issuecomment-1139017499. "apache_beam/transforms/window_test.py" <ins> # See https://github.com/apache/beam/issues/25390. "apache_beam/coders/slow_coders_test.py" "apache_beam/dataframe/pandas_doctests_test.py" "apache_beam/typehints/typed_pipeline_test.py" "apache_beam/coders/fast_coders_test.py" "apache_beam/dataframe/schemas_test.py" </ins> ]; disabledTests = [


Question: Currently, most functions work without problem. However, when I try to add new paths to search dictionaries, it crashes with the following error message: Steps to reproduce the behavior: goldendict Edit Dictionaries Source Add crashes A dialog should pop up to select the path. Reproduced using the latest master branch of this repo. Using startx and qtile as the window manager I've submitted a PR to fix this issue (see ) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --

, libXtst, libvorbis, hunspell, lzo, xz, bzip2, libiconv , qtbase, qtsvg, qtwebkit, qtx11extras, qttools, qmake , wrapQtAppsHook <ins> , wrapGAppsHook </ins> , withCC ? true, opencc , withEpwing ? true, libeb , withExtraTiff ? true, libtiff


Question: Currently, most functions work without problem. However, when I try to add new paths to search dictionaries, it crashes with the following error message: Steps to reproduce the behavior: goldendict Edit Dictionaries Source Add crashes A dialog should pop up to select the path. Reproduced using the latest master branch of this repo. Using startx and qtile as the window manager I've submitted a PR to fix this issue (see ) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --

--replace "opencc.2" "opencc" ''; <del> nativeBuildInputs = [ pkg-config qmake wrapQtAppsHook ]; </del> <ins> nativeBuildInputs = [ pkg-config qmake wrapQtAppsHook wrapGAppsHook ]; </ins> buildInputs = [ qtbase qtsvg qtwebkit qttools libvorbis hunspell xz lzo


Question: sakura terminal emulator terminates when trying to change color by context menu with following error: GLib-GIO-ERROR *: No GSettings schemas are installed on the system [1] 9932 trace trap sakura run sakura, right click to popup context menu : options -select colors -(click on color field to open color chooser) Here is a thread that discusses the issue. it seems that the color-chooser gui description is missing that is needed by sakura. should include gsettings as runtime dependency. actually it has gtk3 package as dependency which provides those schemata, however it obvious doesn't look in the right path. this kind of error got fixed for System: (17.03pre98008. (Gorilla)) Nix version: (nix-env (Nix) 1.11.4) Nixpkgs version: ("17.03pre98008.")

<del> { stdenv, fetchurl, cmake, pkgconfig, gtk3, perl, vte, pcre, glib }: </del> <ins> { stdenv, fetchurl, cmake, pkgconfig, gtk3, perl, vte, pcre, glib , makeWrapper }: </ins> stdenv.mkDerivation rec { name = "sakura-${version}";


Question: sakura terminal emulator terminates when trying to change color by context menu with following error: GLib-GIO-ERROR *: No GSettings schemas are installed on the system [1] 9932 trace trap sakura run sakura, right click to popup context menu : options -select colors -(click on color field to open color chooser) Here is a thread that discusses the issue. it seems that the color-chooser gui description is missing that is needed by sakura. should include gsettings as runtime dependency. actually it has gtk3 package as dependency which provides those schemata, however it obvious doesn't look in the right path. this kind of error got fixed for System: (17.03pre98008. (Gorilla)) Nix version: (nix-env (Nix) 1.11.4) Nixpkgs version: ("17.03pre98008.")

nativeBuildInputs = [ cmake perl pkgconfig ]; <del> buildInputs = [ gtk3 vte pcre glib ]; </del> <ins> buildInputs = [ makeWrapper gtk3 vte pcre glib ]; # Wrapper sets path to gsettings-schemata so sakura knows where to find colorchooser, fontchooser ... postInstall = "wrapProgram $out/bin/sakura --suffix XDG_DATA_DIRS : ${gtk3}/share/gsettings-schemas/${gtk3.name}/"; </ins> meta = with stdenv.lib; { description = "A terminal emulator based on GTK and VTE";


Question: sakura terminal emulator terminates when trying to change color by context menu with following error: GLib-GIO-ERROR *: No GSettings schemas are installed on the system [1] 9932 trace trap sakura run sakura, right click to popup context menu : options -select colors -(click on color field to open color chooser) Here is a thread that discusses the issue. it seems that the color-chooser gui description is missing that is needed by sakura. should include gsettings as runtime dependency. actually it has gtk3 package as dependency which provides those schemata, however it obvious doesn't look in the right path. this kind of error got fixed for System: (17.03pre98008. (Gorilla)) Nix version: (nix-env (Nix) 1.11.4) Nixpkgs version: ("17.03pre98008.")

makeFlags = [ "-e" ]; makeFlagsArray="LIBS=-lgc"; <del> meta = { </del> <ins> meta = with stdenv.lib ; { </ins> description = "Follow a symlink and print out its target file"; longDescription = '' A commandline program that chases symbolic filesystems links to the original file ''; homepage = "https://qa.debian.org/developer.php?login=rotty%40debian.org"; <del> license = stdenv.lib.licenses.gpl2Plus; maintainers = [ stdenv.lib.maintainers.polyrod ]; platforms = stdenv.lib.platforms.all; </del> <ins> license = licenses.gpl2Plus; maintainers = [ maintainers.polyrod ]; platforms = platforms.all; </ins> }; }


Question: Steps to reproduce the behavior: package is marked as broken I marked this package as broken starting with linux 6.2 because enables by default. The binary blobs included with the nvidia driver are not compiled with support for IBT and nvidia hasn't been able to update their internal toolchain to support it at this point. Rather than leave it broken, we should probably check if the driver is built using the proprietary blobs and add the kernel parameter starting with linux 6.2. <!-- 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.

# If requested enable modesetting via kernel parameter. boot.kernelParams = optional (offloadCfg.enable || cfg.modesetting.enable) "nvidia-drm.modeset=1" ++ optional cfg.powerManagement.enable "nvidia.NVreg_PreserveVideoMemoryAllocations=1" <del> ++ optional cfg.open "nvidia.NVreg_OpenRmEnableUnsupportedGpus=1"; </del> <ins> ++ optional cfg.open "nvidia.NVreg_OpenRmEnableUnsupportedGpus=1" # proprietary driver is not compiled with support for X86_KERNEL_IBT ++ optional (!cfg.open && config.boot.kernelPackages.kernel.kernelAtLeast "6.2") "ibt=off"; </ins> services.udev.extraRules = ''


Question: Steps to reproduce the behavior: package is marked as broken I marked this package as broken starting with linux 6.2 because enables by default. The binary blobs included with the nvidia driver are not compiled with support for IBT and nvidia hasn't been able to update their internal toolchain to support it at this point. Rather than leave it broken, we should probably check if the driver is built using the proprietary blobs and add the kernel parameter starting with linux 6.2. <!-- 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.

platforms = [ "x86_64-linux" ] ++ optionals (!i686bundled) [ "i686-linux" ]; maintainers = with maintainers; [ jonringer ]; priority = 4; # resolves collision with xorg-server's "lib/xorg/modules/extensions/libglx.so" <del> # proprietary driver currently does not support X86_KERNEL_IBT, which is scheduled to be added in linux 6.2 broken = broken || (kernel != null && kernel.kernelAtLeast "6.2"); </del> <ins> inherit broken; </ins> }; };


Question:
A ends with the following: commit -rebuild switch System: NixOS: Nix version:nix-env (Nix) 1.11.4 Nixpkgs version:
Do you have grub on an encrypted partition and have ?
no, I don't have that option specified anywhere at all. Also, the error has since disappeared after moving to a fresher .
GRUBENABLECRYPTODISK=y' in file That seemed to say that, no idea what the issue was then, so I'm closing this, please reopen if it occurs again.

{ stdenv, fetchurl, gmp }: stdenv.mkDerivation rec { <del> name = "ikarus-0.0.3"; </del> <ins> version = "0.0.3"; name = "ikarus-${version}"; </ins> src = fetchurl { <del> url = "http://ikarus-scheme.org/${name}.tar.gz"; </del> <ins> url = "http://launchpad.net/ikarus/0.0/${version}/+download/${name}.tar.gz"; </ins> sha256 = "0d4vqwqfnj39l0gar2di021kcf6bfpkc6g40yapkmxm6sxpdcvjv"; };


Question: The script does not (consistently) follow symlinks in the parameter, which it uses to locate the system closure to activate. This breaks when used with , which creates a symlink. When the kernel command line has , the script looks for , which does not exist. ~(Workaround: generationsDir users can pass instead.)~ Update: That doesn't work either. with will fail in strange ways, ultimately stemming from not calling . System should boot successfully when using generationsDir and systemd-initrd together. Symlink resolution was partially addressed in , but only for cases where is a symlink. Booting also fails if the given is a symlink, or if any part of the path to is an absolute symlink (because filesystems are mounted at , not ). I took a stab at fixing this in (), but it does not handle absolute symlinks correctly. Since generationsDir creates absolute symlinks to , this fix alone does not fix compatibility. ( changes those symlinks to relative, and together the PRs fix the compatibility issue.) Ideally, the script should follow symlinks in any part of the param, even if they cross filesystems. One option is to resolve the links inside the chroot. I couldn't figure out a clean way to make this work. (Can we trust that will have the we're looking for? We can't use because we're still trying to establish which system that is.) Another option is to somehow . (At time of writing, this question has no answers.) (guessing based on git log):

case $o in init=*) IFS== read -r -a initParam <<< "$o" <del> closure="$(dirname "''${initParam[1]}")" </del> <ins> closure="''${initParam[1]}" </ins> ;; esac done


Question: The script does not (consistently) follow symlinks in the parameter, which it uses to locate the system closure to activate. This breaks when used with , which creates a symlink. When the kernel command line has , the script looks for , which does not exist. ~(Workaround: generationsDir users can pass instead.)~ Update: That doesn't work either. with will fail in strange ways, ultimately stemming from not calling . System should boot successfully when using generationsDir and systemd-initrd together. Symlink resolution was partially addressed in , but only for cases where is a symlink. Booting also fails if the given is a symlink, or if any part of the path to is an absolute symlink (because filesystems are mounted at , not ). I took a stab at fixing this in (), but it does not handle absolute symlinks correctly. Since generationsDir creates absolute symlinks to , this fix alone does not fix compatibility. ( changes those symlinks to relative, and together the PRs fix the compatibility issue.) Ideally, the script should follow symlinks in any part of the param, even if they cross filesystems. One option is to resolve the links inside the chroot. I couldn't figure out a clean way to make this work. (Can we trust that will have the we're looking for? We can't use because we're still trying to establish which system that is.) Another option is to somehow . (At time of writing, this question has no answers.) (guessing based on git log):

exit 1 fi <ins> # Resolve symlinks in the init parameter. We need this for some boot loaders # (e.g. boot.loader.generationsDir). closure="$(chroot /sysroot ${pkgs.coreutils}/bin/realpath "$closure")" # Assume the directory containing the init script is the closure. closure="$(dirname "$closure")" </ins> # If we are not booting a NixOS closure (e.g. init=/bin/sh), # we don't know what root to prepare so we don't do anything if ! [ -x "/sysroot$(readlink "/sysroot$closure/prepare-root" || echo "$closure/prepare-root")" ]; then


Question: Package name: wpgtk Latest released version: 6.5.7 <!-- Search your package here: --- Current version on the unstable channel: 6.5.5 Current version on the stable/release channel: 6.5.5 <!-- 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.

python3Packages.buildPythonApplication rec { pname = "wpgtk"; <del> version = "6.5.5"; </del> <ins> version = "6.5.7"; </ins> src = fetchFromGitHub { owner = "deviantfero"; repo = "wpgtk"; rev = version; <del> sha256 = "sha256-g3flxQNiNta+uL4t21Lhpij8b5yB78SJLGaFpTcm9fE="; </del> <ins> sha256 = "sha256-rHNni0nDghc5kI1sWHAb5ODr4buBz65eUEB1qWpbTTs="; </ins> }; nativeBuildInputs = [


Question:
Changes introduced in forcing package (or whatever the option is set to) installation even if the set to . This is because the module is unconditionally adding the package to the : Steps to reproduce the behavior: both and to in order to avoid enabling the service or systemd overriding the package with . installed packages, for example using the command. An package is installed into the system: An package should not be installed into the system. I am on a quest to build a minimal NixOS system for usage in LXC containers and trying to trim things down to the minimum, without having to resort to forking, overriding, patching and maintaining individual modules. I am happy to open up a PR to move the package assignment to the block: but would like to check if anyone has any objections or reasons why I shouldn't be doing so. appreciate any insights  Please run and paste the result.
As the author of that PR I have no objections to restoring the old behaviour.

exit 1 '' else configText; <del> environment.systemPackages = [ cfg.package ]; </del> } (mkIf cfg.enable { networking.resolvconf.package = pkgs.openresolv; <ins> environment.systemPackages = [ cfg.package ]; </ins> systemd.services.resolvconf = { description = "resolvconf update";


Question:
Steps to reproduce the behavior: (the current version in ) I was having the same issue that was fixed by until a few days ago and built and worked flawlessly. I am currently using the version it is supposedly trying to build. returns , so I do not understand why the build is needed in the first place. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (because you made the last commit) Please run and paste the result.
I tried rebuilding today after the fix you committed (thank you for being so quick), I am still receiving the same error. Is there something in particular I need to do for the fix to propogate? I know that there is a little lag before a commit comes in from , but I thought 3 days later would be enough?
The fix is now on and , so if you are on either, I guess you just need to update the channel. Otherwise, the following command should work:
FWIW, is also a handy tool for checking the status of a PR's movement into the various channels.
that worked, thank you. this is also very useful, will put it in my bookmarks!

hash = "sha256-4VC1fwQh9L3c5tgLUaC36p9QHL4dR2vkWc2XlNl0Xzw="; }; <del> # Disable version check </del> postPatch = '' <ins> # Drop broken version specifier sed -i '/python_requires/d' setup.py # Disable version check </ins> substituteInPlace raphodo/constants.py  --replace "disable_version_check = False" "disable_version_check = True" '';


Question:
Steps to reproduce the behavior: -shell -p quickbms Please run and paste the result.
It's possible that this package just isn't buildable One of the errors encountered is: is not supported in recent openssl versions.

<ins> --- src/Makefile	2023-05-25 18:16:56.000296653 +0900 +++ src/Makefile	2023-05-25 18:17:00.772272861 +0900 @@ -23,7 +23,6 @@ EXTRA_TARGETS  = libs/amiga/amiga.s libs/powzix/*.cpp CFLAGS += -msse2 endif -USE_OPENSSL	= 1 endif # -liconv and -fPIC are necessary on Android </ins>


Question:
Steps to reproduce the behavior: -shell -p quickbms Please run and paste the result.
It's possible that this package just isn't buildable One of the errors encountered is: is not supported in recent openssl versions.

<del> { stdenv, lib, fetchzip, bzip2, lzo, openssl, zlib }: </del> <ins> { stdenv , lib , fetchzip , fetchpatch , bzip2 , lzo , openssl_1_1 , opensslSupport ? false , zlib }: </ins> stdenv.mkDerivation rec { version = "0.11.0";


Question:
Steps to reproduce the behavior: -shell -p quickbms Please run and paste the result.
It's possible that this package just isn't buildable One of the errors encountered is: is not supported in recent openssl versions.

hash = "sha256-uQKTE36pLO8uhrX794utqaDGUeyqRz6zLCQFA7DYkNc="; }; <del> buildInputs = [ bzip2 lzo openssl zlib ]; </del> <ins> patches = [ # Fix errors on x86_64 and _rotl definition (fetchpatch { name = "0001-fix-compile.patch"; url = "https://aur.archlinux.org/cgit/aur.git/plain/fix-compile.patch?h=quickbms&id=a2e3e4638295d7cfe39513bfef9447fb23154a6b"; hash = "sha256-49fT/L4BNzMYnq1SXhFMgSDLybLkz6KSbgKmUpZZu08="; stripLen = 1; }) ] ++ lib.optional (!opensslSupport) ./0002-disable-openssl.patch; buildInputs = [ bzip2 lzo zlib ] ++ lib.optional (opensslSupport) openssl_1_1; </ins> makeFlags = [ "PREFIX=$(out)" ];


Question: Project description CLI for interacting with Scalr. Metadata homepage URL: source URL: license: apache 2 platforms: windows, linux, darwin

githubId = 6689924; name = "David Terry"; }; <ins> dylanmtaylor = { email = "dylan@dylanmtaylor.com"; github = "dylamtaylor"; githubId = 277927; name = "Dylan Taylor"; }; </ins> dysinger = { email = "tim@dysinger.net"; github = "dysinger";


Question: Project description CLI for interacting with Scalr. Metadata homepage URL: source URL: license: apache 2 platforms: windows, linux, darwin

<ins> { lib , buildGoModule , fetchFromGitHub }: buildGoModule rec { pname = "scalr-cli"; version = "0.14.5"; src = fetchFromGitHub { owner = "Scalr"; repo = "scalr-cli"; rev = "v${version}"; hash = "sha256-X/fZDM1OYw1a0la8os9TFUrl1h5BnO+C40h2XH32vmw="; }; vendorHash = "sha256-EdDhq6LnxagutxjiOoYElhHVnSKhr/Ekt928gSooPYY="; ldflags = [ "-s" "-w" ]; preConfigure = '' # Set the version. substituteInPlace main.go --replace '"0.0.0"' '"${version}"' ''; postInstall = '' mv $out/bin/cli $out/bin/scalr ''; doCheck = false; # Skip tests as they require creating actual Scalr resources. meta = with lib; { description = "A command-line tool that communicates directly with the Scalr API."; homepage = "https://github.com/Scalr/scalr-cli"; changelog = "https://github.com/Scalr/scalr-cli/releases/tag/v${version}"; license = licenses.asl20; maintainers = with maintainers; [ dylanmtaylor ]; mainProgram = "scalr"; platforms = platforms.unix; }; } </ins>


Question: Project description CLI for interacting with Scalr. Metadata homepage URL: source URL: license: apache 2 platforms: windows, linux, darwin

sampler = callPackage ../applications/misc/sampler { }; <ins> scalr-cli = callPackage ../tools/admin/scalr-cli { }; </ins> shairplay = callPackage ../servers/shairplay { avahi = avahi-compat; }; shairport-sync = callPackage ../servers/shairport-sync { };


Question:
Package name: oracle-instantclient Latest released version:21.9.0.0.0 <!-- Search your package here: --- Current version on the unstable channel:19.16.0.0.0 Current version on the stable/release channel:19.16.0.0.0 <!-- 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! -- looks like it tried to upgrade v19 of instant client, but it is stale and not targeting v21. 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.
It looks like you were the last one to touch instant client.
Package sources:

# determine the version number, there might be different ones per architecture version = { <del> x86_64-linux = "19.16.0.0.0"; </del> <ins> x86_64-linux = "21.9.0.0.0"; </ins> aarch64-linux = "19.10.0.0.0"; <del> x86_64-darwin = "19.3.0.0.0"; </del> <ins> x86_64-darwin = "19.8.0.0.0"; </ins> }.${stdenv.hostPlatform.system} or throwSystem; directory = { <del> x86_64-linux = "1916000"; </del> <ins> x86_64-linux = "219000"; </ins> aarch64-linux = "191000"; <del> x86_64-darwin = "193000"; </del> <ins> x86_64-darwin = "198000"; </ins> }.${stdenv.hostPlatform.system} or throwSystem; # hashes per component and architecture hashes = { x86_64-linux = { <del> basic = "sha256-Sq1rWvbC1YME7EjSYPaP2g+1Xxxkk4ZkGaBmLo2cKcQ="; sdk = "sha256-yJ8f/Hlq6vZoPxv+dfY4z1E7rWvcqlK+ou0SU0KKlEI="; sqlplus = "sha256-C44srukpCB9et9UWm59daJmU83zr0HAktnWv7R42Irw="; tools = "sha256-GP4E1REIoU3lctVYmLsAiwTJEvGRpCmOFlRuZk+A8HE="; odbc = "sha256-JECxK7Ia1IJtve2goZJdTkvm5NJjqB2rc6k5BXUt3oA="; </del> <ins> basic = "sha256-wiygUvZFYvjp5pndv3b9yTPxe8sC5HZkJ7jZqO1Mss8="; sdk = "sha256-ehqHV52yLRe8ehrKqpLaN0HnN3zjHU7WrfjtqvQadgY="; sqlplus = "sha256-tYvoG+7l5jXyTpxFUYZXaHCT0xGDeah78AinJ2qIsE8="; tools = "sha256-6K2Ni0ZqqpqCrGFrBD06s0QNjNEDtNPrvDQ1U97lTKY="; odbc = "sha256-yTANMLhaEqm9/ZEVqhEn1Gl8eJukgvqpqdaMRjxWxgs="; </ins> }; aarch64-linux = { basic = "sha256-DNntH20BAmo5kOz7uEgW2NXaNfwdvJ8l8oMnp50BOsY=";


Question:
Package name: oracle-instantclient Latest released version:21.9.0.0.0 <!-- Search your package here: --- Current version on the unstable channel:19.16.0.0.0 Current version on the stable/release channel:19.16.0.0.0 <!-- 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! -- looks like it tried to upgrade v19 of instant client, but it is stale and not targeting v21. 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.
It looks like you were the last one to touch instant client.
Package sources:

odbc = "sha256-T+RIIKzZ9xEg/E72pfs5xqHz2WuIWKx/oRfDrQbw3ms="; }; x86_64-darwin = { <del> basic = "f4335c1d53e8188a3a8cdfb97494ff87c4d0f481309284cf086dc64080a60abd"; sdk = "b46b4b87af593f7cfe447cfb903d1ae5073cec34049143ad8cdc9f3e78b23b27"; sqlplus = "f7565c3cbf898b0a7953fbb0017c5edd9d11d1863781588b7caf3a69937a2e9e"; tools = "b2bc474f98da13efdbc77fd05f559498cd8c08582c5b9038f6a862215de33f2c"; odbc = "f91da40684abaa866aa059eb26b1322f2d527670a1937d678404c991eadeb725"; </del> <ins> basic = "sha256-V+1BmPOhDYPNXdwkcsBY1MOwt4Yka66/a7/HORzBIIc="; sdk = "sha256-D6iuTEQYqmbOh1z5LnKN16ga6vLmjnkm4QK15S/Iukw="; sqlplus = "sha256-08uoiwoKPZmTxLZLYRVp0UbN827FXdhOukeDUXvTCVk="; tools = "sha256-1xFFGZapFq9ogGQ6ePSv4PrXl5qOAgRZWAp4mJ5uxdU="; odbc = "sha256-S6+5P4daK/+nXwoHmOkj4DIkHtwdzO5GOkCCI612bRY="; </ins> }; }.${stdenv.hostPlatform.system} or throwSystem;


Question:
Package name: oracle-instantclient Latest released version:21.9.0.0.0 <!-- Search your package here: --- Current version on the unstable channel:19.16.0.0.0 Current version on the stable/release channel:19.16.0.0.0 <!-- 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! -- looks like it tried to upgrade v19 of instant client, but it is stale and not targeting v21. 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.
It looks like you were the last one to touch instant client.
Package sources:

sourceProvenance = with sourceTypes; [ binaryBytecode ]; license = licenses.unfree; platforms = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" ]; <del> maintainers = with maintainers; [ flokli ]; </del> <ins> maintainers = with maintainers; [ flokli dylanmtaylor ]; </ins> hydraPlatforms = [ ]; }; }


Question: Package name: swayws Latest released version: 1.2.0 <!-- Search your package here: --- Current version on the unstable channel: 2022-03-10 Current version on the stable/release channel: 2022-03-10 <!-- 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.

<ins> diff --git a/Cargo.lock b/Cargo.lock index f01f824..e00d079 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -328,7 +328,7 @@ dependencies = [ [[package]] name = "swayws" -version = "1.1.1" +version = "1.2.0" dependencies = [ "clap", "env_logger", </ins>


Question: Package name: swayws Latest released version: 1.2.0 <!-- Search your package here: --- Current version on the unstable channel: 2022-03-10 Current version on the stable/release channel: 2022-03-10 <!-- 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.

rustPlatform.buildRustPackage rec { pname = "swayws"; <del> version = "unstable-2022-03-10"; </del> <ins> version = "1.2.0"; </ins> src = fetchFromGitLab { owner = "w0lff"; repo = pname; <del> rev = "514f3c664439cf2c11bb9096c7e1d3b8c0b898a2"; sha256 = "sha256-vUnbn79v08riYLMBI8BxeBPpe/pHOWlraG7QAaohw3s="; </del> <ins> rev = "v${version}"; sha256 = "sha256-f0kXy7/31imgHHqKPmW9K+QrLqroaPaXwlJkzOoezRU="; </ins> }; <del> cargoSha256 = "sha256-PvKpcTewajvbzUHPssBahWVcAQB3V/aMmOJ/wA0Nrv4="; </del> <ins> cargoSha256 = "sha256-VYT6wV59fraAoJgR/i6GlO8s7LUoehGtxPAggEL1eLo="; # Required patch until upstream fixes https://gitlab.com/w0lff/swayws/-/issues/1 cargoPatches = [ ./ws-update-Cargo-lock.patch ]; </ins> # swayws does not have any tests doCheck = false;


Question:
This is a continuation of the topic from the initial "upgrade datadog-agent to v7" ticket - see for details on that. The is a metrics and log collection agent intended to run on linux systems for use with 's paid service. On other linux distributions, installing the datadog-agent includes the integration/plugin code, there is no separate install for those, or post-install steps to install the plugins (only config to activate/configure them). Configure the in , and add some extra integration, such as the docker integration. and look at the installed, the plugins are not available. You should see logs from the agent about those. When configuring the datadog-agent, the standard integrations/plugins (docker, nginx, apache, postgres, etc, etc) should be installed and available to the agent if the agent is configured to use them. Please run and paste the result.
There's still something wrong with the Python environment.
Most likely we need to use pyproject to build it properly: That results into missing ddtrace package, which needs to be .
Looks like setuptools wasn't building the and modules. and should fix the integrations. Datadog is planning on dropping setuptools, so we should switch over to pyproject. The blocker is that there are a number of missing dependencies that aren't on nixpkgs yet, but I've started working on that. the Docker integration was rewritten in Go and is now built together with the . You can enable it with: I have no idea why they're now called Yeah, we need to rethink how these integrations are enabled. Now that some of them are part of the , it's become quite a pain to set up.
Fixed in
Thanks! Note that, to get this to run for me, nixpkgs needed an overlay specifying that all packages wanting would get . That looks liked: It seems that, while is deprecated and python 3 is "the default", the package maps to , so a lot of packages effectively default to python 2. Thanks to for coming up with that workaround. I haven't yet see the docker integration work, but I've seen the plugins and such install, so that is promising, and it's likely the last bits are in my config to sort out.
are you on an older release of nixpkgs? has been set to for the datadog integrations since .
We determined the evaluation error came from here: Did we mess that up somehow?
There's a good chance that can be removed from there with no impact. We recently did so for the systemd service.
is a vestige of the old agent. It was a python wrapper that launched that jmx java thing. can most definitely be removed check is broken. I imagine we'd need to package

<ins> { lib , buildPythonPackage , fetchPypi , pytestCheckHook , pythonOlder , setuptools }: buildPythonPackage rec { pname = "binary"; version = "1.0.0"; format = "pyproject"; disabled = pythonOlder "3.7"; src = fetchPypi { inherit pname version; hash = "sha256-bsAQ5Y9zMevIvJY42+bGbWNd5g1YGLByO+9N6tDsKKY="; }; nativeBuildInputs = [ setuptools ]; nativeCheckInputs = [ pytestCheckHook ]; pythonImportsCheck = [ "binary" "binary.core" ]; meta = with lib; { description = "Easily convert between binary and SI units (kibibyte, kilobyte, etc.)"; homepage = "https://github.com/ofek/binary"; license = with licenses; [ asl20 mit ]; maintainers = with maintainers; [ ]; }; } </ins>


Question:
This is a continuation of the topic from the initial "upgrade datadog-agent to v7" ticket - see for details on that. The is a metrics and log collection agent intended to run on linux systems for use with 's paid service. On other linux distributions, installing the datadog-agent includes the integration/plugin code, there is no separate install for those, or post-install steps to install the plugins (only config to activate/configure them). Configure the in , and add some extra integration, such as the docker integration. and look at the installed, the plugins are not available. You should see logs from the agent about those. When configuring the datadog-agent, the standard integrations/plugins (docker, nginx, apache, postgres, etc, etc) should be installed and available to the agent if the agent is configured to use them. Please run and paste the result.
There's still something wrong with the Python environment.
Most likely we need to use pyproject to build it properly: That results into missing ddtrace package, which needs to be .
Looks like setuptools wasn't building the and modules. and should fix the integrations. Datadog is planning on dropping setuptools, so we should switch over to pyproject. The blocker is that there are a number of missing dependencies that aren't on nixpkgs yet, but I've started working on that. the Docker integration was rewritten in Go and is now built together with the . You can enable it with: I have no idea why they're now called Yeah, we need to rethink how these integrations are enabled. Now that some of them are part of the , it's become quite a pain to set up.
Fixed in
Thanks! Note that, to get this to run for me, nixpkgs needed an overlay specifying that all packages wanting would get . That looks liked: It seems that, while is deprecated and python 3 is "the default", the package maps to , so a lot of packages effectively default to python 2. Thanks to for coming up with that workaround. I haven't yet see the docker integration work, but I've seen the plugins and such install, so that is promising, and it's likely the last bits are in my config to sort out.
are you on an older release of nixpkgs? has been set to for the datadog integrations since .
We determined the evaluation error came from here: Did we mess that up somehow?
There's a good chance that can be removed from there with no impact. We recently did so for the systemd service.
is a vestige of the old agent. It was a python wrapper that launched that jmx java thing. can most definitely be removed check is broken. I imagine we'd need to package

bimmer-connected = callPackage ../development/python-modules/bimmer-connected { }; <ins> binary = callPackage ../development/python-modules/binary { }; </ins> binaryornot = callPackage ../development/python-modules/binaryornot { }; bincopy = callPackage ../development/python-modules/bincopy { };


Question: Project description Gut is a CLI designed to make Git easier to use. Metadata homepage URL: source URL: license: mit platforms: linux, darwin, windows

<ins> { buildGoModule , fetchFromGitHub , lib , nix-update-script }: buildGoModule rec { pname = "gut"; version = "0.2.7"; src = fetchFromGitHub { owner = "julien040"; repo = "gut"; rev = version; sha256 = "sha256-qmp6QWmyharyTzUVXlX/oJZWbeyegX/u8/vzi/pTSaA="; }; vendorSha256 = "sha256-E4jr+dskBdVXj/B5RW1AKyxxr+f/+ZW42OTO9XbCLuw="; ldflags = [ "-s" "-w" "-X github.com/julien040/gut/src/telemetry.gutVersion=${version}" ]; # Checks if `/home` exists doCheck = false; passthru.updateScript = nix-update-script { }; meta = { description = "An easy-to-use git client for Windows, macOS, and Linux"; homepage = "https://github.com/slackhq/go-audit"; maintainers = [ lib.maintainers.paveloom ]; license = [ lib.licenses.mit ]; }; } </ins>


Question: Project description Gut is a CLI designed to make Git easier to use. Metadata homepage URL: source URL: license: mit platforms: linux, darwin, windows

gst = callPackage ../applications/version-management/gst { }; <ins> gut = callPackage ../applications/version-management/gut { }; </ins> hred = callPackage ../development/tools/hred { }; hub = callPackage ../applications/version-management/hub { };


Question:
libnfc from the cache does not seem to work for me: ~ What happens is a null-pointer dereference somewhere inside IOKit: ~ I am really not sure what is going on, but what troubles me is that I cannot reproduce the build on my laptop: apparently, the examples depend on readline, which is not listed as a dependency. ~ How does the manage to succeed on Hydra? What’s wrong with libnfc or libusb built on Hydra? After I as a dependency the build succeded and the resulting libnfc is fully functional.
Do you use sandboxing?
I honestly do not know how it works and if it is enabled by default.
I have opened to address the readline issue (which is probably completely unrelated).
I ask because it could account for the difference (that is, there could be an impurity in the build, causing it to break in unsandboxed environments EDIT: or allowing it to succeed, whichever). It's not enabled by default, but I'm not sure about how stuff works on MacOS wrt sandboxing.
Hm, you have a point. I guess it’s not sandboxing but something similar: building in a pure nix-shell yields non-functional utils.
Ok, now I see. Without it found Homebrew (as the expression does not depend on and therefore the system is not shadowed) and it told it about libusb installed from Homebrew. So, apparently libusb is the culprit.
On my end, I've found that with to the build environment, the readline error manifests (whereas it builds fine otherwise); adding both & allows it to build. There's no segfault, however. As a side note, FWIW, is much weaker than the isolation provided by the build sandbox (it just clears most of the shell environment, you can still traverse the rootfs & pick up all sorts of impurities).
How did you build this? Do you see the same result with ?
Try running: in your nix-shell. see
We need some proper way to fix that.
We could have it set in at least temporarily. There are no real side effects to just setting it besides the potential impurities.
I spent most of yesterday trying to debug the issue but with no luck: I did not manage to build libusb and libnfc with debug symbols (I have no idea how works on macOS; apparently it puts debug symbols into but does not copy them to the resulting binary, therefore, when the library is installed into the store, debug symbols are gone. It would be great if someone taught me how to do this properly).
What exactly is that impure thing that makes pull system CF?
In this case it's the framework, that's linked against the system CoreFoundation, I'm still testing some stuff but I'm pretty sure that I have a proper solution.

<ins> # On Mac OS X, frameworks are linked to the system CoreFoundation but # dynamic libraries built with nix use a pure version of CF this # causes segfaults for binaries that depend on it at runtime.  This # can be solved in two ways. # 1. Rewrite references to the pure CF using this setup hook, this # works for the simple case but this can still cause problems if other # dependencies (eg. python) use the pure CF. # 2. Create a wrapper for the binary that sets DYLD_FRAMEWORK_PATH to # /System/Library/Frameworks.  This will make everything load the # system's CoreFoundation framework while still keeping the # dependencies pure for other packages. fixupOutputHooks+=('fixDarwinFrameworksIn $prefix') fixDarwinFrameworks() { local systemPrefix='/System/Library/Frameworks' for fn in "$@"; do if [ -L "$fn" ]; then continue; fi echo "$fn: fixing dylib" for framework in $(otool -L "$fn" | awk '/CoreFoundation.framework/ {print $1}'); do install_name_tool -change "$framework" "$systemPrefix/CoreFoundation.framework/Versions/A/CoreFoundation" "$fn" >&2 done done } fixDarwinFrameworksIn() { local dir="$1" fixDarwinFrameworks $(find "$dir" -name "*.dylib") } </ins>


Question:
libnfc from the cache does not seem to work for me: ~ What happens is a null-pointer dereference somewhere inside IOKit: ~ I am really not sure what is going on, but what troubles me is that I cannot reproduce the build on my laptop: apparently, the examples depend on readline, which is not listed as a dependency. ~ How does the manage to succeed on Hydra? What’s wrong with libnfc or libusb built on Hydra? After I as a dependency the build succeded and the resulting libnfc is fully functional.
Do you use sandboxing?
I honestly do not know how it works and if it is enabled by default.
I have opened to address the readline issue (which is probably completely unrelated).
I ask because it could account for the difference (that is, there could be an impurity in the build, causing it to break in unsandboxed environments EDIT: or allowing it to succeed, whichever). It's not enabled by default, but I'm not sure about how stuff works on MacOS wrt sandboxing.
Hm, you have a point. I guess it’s not sandboxing but something similar: building in a pure nix-shell yields non-functional utils.
Ok, now I see. Without it found Homebrew (as the expression does not depend on and therefore the system is not shadowed) and it told it about libusb installed from Homebrew. So, apparently libusb is the culprit.
On my end, I've found that with to the build environment, the readline error manifests (whereas it builds fine otherwise); adding both & allows it to build. There's no segfault, however. As a side note, FWIW, is much weaker than the isolation provided by the build sandbox (it just clears most of the shell environment, you can still traverse the rootfs & pick up all sorts of impurities).
How did you build this? Do you see the same result with ?
Try running: in your nix-shell. see
We need some proper way to fix that.
We could have it set in at least temporarily. There are no real side effects to just setting it besides the potential impurities.
I spent most of yesterday trying to debug the issue but with no luck: I did not manage to build libusb and libnfc with debug symbols (I have no idea how works on macOS; apparently it puts debug symbols into but does not copy them to the resulting binary, therefore, when the library is installed into the store, debug symbols are gone. It would be great if someone taught me how to do this properly).
What exactly is that impure thing that makes pull system CF?
In this case it's the framework, that's linked against the system CoreFoundation, I'm still testing some stuff but I'm pretty sure that I have a proper solution.

propagatedBuildInputs = deps; <ins> # don't use pure CF for dylibs that depend on frameworks setupHook = ../../../build-support/setup-hooks/fix-darwin-frameworks.sh; </ins> # allows building the symlink tree __impureHostDeps = [ "/System/Library/Frameworks/${name}.framework" ];


Question:
libnfc from the cache does not seem to work for me: ~ What happens is a null-pointer dereference somewhere inside IOKit: ~ I am really not sure what is going on, but what troubles me is that I cannot reproduce the build on my laptop: apparently, the examples depend on readline, which is not listed as a dependency. ~ How does the manage to succeed on Hydra? What’s wrong with libnfc or libusb built on Hydra? After I as a dependency the build succeded and the resulting libnfc is fully functional.
Do you use sandboxing?
I honestly do not know how it works and if it is enabled by default.
I have opened to address the readline issue (which is probably completely unrelated).
I ask because it could account for the difference (that is, there could be an impurity in the build, causing it to break in unsandboxed environments EDIT: or allowing it to succeed, whichever). It's not enabled by default, but I'm not sure about how stuff works on MacOS wrt sandboxing.
Hm, you have a point. I guess it’s not sandboxing but something similar: building in a pure nix-shell yields non-functional utils.
Ok, now I see. Without it found Homebrew (as the expression does not depend on and therefore the system is not shadowed) and it told it about libusb installed from Homebrew. So, apparently libusb is the culprit.
On my end, I've found that with to the build environment, the readline error manifests (whereas it builds fine otherwise); adding both & allows it to build. There's no segfault, however. As a side note, FWIW, is much weaker than the isolation provided by the build sandbox (it just clears most of the shell environment, you can still traverse the rootfs & pick up all sorts of impurities).
How did you build this? Do you see the same result with ?
Try running: in your nix-shell. see
We need some proper way to fix that.
We could have it set in at least temporarily. There are no real side effects to just setting it besides the potential impurities.
I spent most of yesterday trying to debug the issue but with no luck: I did not manage to build libusb and libnfc with debug symbols (I have no idea how works on macOS; apparently it puts debug symbols into but does not copy them to the resulting binary, therefore, when the library is installed into the store, debug symbols are gone. It would be great if someone taught me how to do this properly).
What exactly is that impure thing that makes pull system CF?
In this case it's the framework, that's linked against the system CoreFoundation, I'm still testing some stuff but I'm pretty sure that I have a proper solution.

fixDarwinDylibNames = makeSetupHook { } ../build-support/setup-hooks/fix-darwin-dylib-names.sh; <ins> fixDarwinFrameworks = makeSetupHook { } ../build-support/setup-hooks/fix-darwin-frameworks.sh; </ins> keepBuildTree = makeSetupHook { } ../build-support/setup-hooks/keep-build-tree.sh; enableGCOVInstrumentation = makeSetupHook { } ../build-support/setup-hooks/enable-coverage-instrumentation.sh;


Question:
libnfc from the cache does not seem to work for me: ~ What happens is a null-pointer dereference somewhere inside IOKit: ~ I am really not sure what is going on, but what troubles me is that I cannot reproduce the build on my laptop: apparently, the examples depend on readline, which is not listed as a dependency. ~ How does the manage to succeed on Hydra? What’s wrong with libnfc or libusb built on Hydra? After I as a dependency the build succeded and the resulting libnfc is fully functional.
Do you use sandboxing?
I honestly do not know how it works and if it is enabled by default.
I have opened to address the readline issue (which is probably completely unrelated).
I ask because it could account for the difference (that is, there could be an impurity in the build, causing it to break in unsandboxed environments EDIT: or allowing it to succeed, whichever). It's not enabled by default, but I'm not sure about how stuff works on MacOS wrt sandboxing.
Hm, you have a point. I guess it’s not sandboxing but something similar: building in a pure nix-shell yields non-functional utils.
Ok, now I see. Without it found Homebrew (as the expression does not depend on and therefore the system is not shadowed) and it told it about libusb installed from Homebrew. So, apparently libusb is the culprit.
On my end, I've found that with to the build environment, the readline error manifests (whereas it builds fine otherwise); adding both & allows it to build. There's no segfault, however. As a side note, FWIW, is much weaker than the isolation provided by the build sandbox (it just clears most of the shell environment, you can still traverse the rootfs & pick up all sorts of impurities).
How did you build this? Do you see the same result with ?
Try running: in your nix-shell. see
We need some proper way to fix that.
We could have it set in at least temporarily. There are no real side effects to just setting it besides the potential impurities.
I spent most of yesterday trying to debug the issue but with no luck: I did not manage to build libusb and libnfc with debug symbols (I have no idea how works on macOS; apparently it puts debug symbols into but does not copy them to the resulting binary, therefore, when the library is installed into the store, debug symbols are gone. It would be great if someone taught me how to do this properly).
What exactly is that impure thing that makes pull system CF?
In this case it's the framework, that's linked against the system CoreFoundation, I'm still testing some stuff but I'm pretty sure that I have a proper solution.

libusb = callPackage ../development/libraries/libusb {}; libusb1 = callPackage ../development/libraries/libusb1 { <del> inherit (darwin) libobjc IOKit; </del> <ins> inherit (darwin) libobjc; inherit (darwin.apple_sdk.frameworks) IOKit; </ins> }; libusbmuxd = callPackage ../development/libraries/libusbmuxd { };