Question: !langJit && !stdenv.hostPlatform.isDarwin && enableShared <del> ; </del> <ins> ; </ins> <del> # For some reason libgcc_s.so has major-version "2" on m68k but # "1" everywhere else.  Might be worth changing this to "*". libgcc_s-version-major = if targetPlatform.isM68k then "2" else "1"; </del> <ins> # For some reason libgcc_s.so has major-version "2" on m68k but # "1" everywhere else.  Might be worth changing this to "*". libgcc_s-version-major = if targetPlatform.isM68k then "2" else "1"; </ins> in (pkg: pkg.overrideAttrs (previousAttrs: lib.optionalAttrs ((!langC) || langJit || enableLibGccOutput) {

On or cross-compiled from , breaks: From : You can either run this on another architecture using . or should not crash: This was responsible for failing to replicate datasets to my ARM NAS. The issue does not_ occur for natively compiled builds. It appears to be a cross-compilation issue only.
It is a bug in / derivations. In non-cross cases it gets copied from used to bid into output: But in cross-case used to build does not yet provide as it needs bits of for it (and the library path is slightly incorrect). One of possible workarounds is to try to add to to get it pulled via from expected location.
We don't do the copying to glibc anymore, but this error still occurs as described on current nixpkgs master.
Yup. cross-compilation never propagated to in any form (and does not today).
Could you please try this PR? It should fix the problem.
With that PR, I'm seeing this on both (a Raspberry Pi CM4) and with QEMU on : Log from aarch64 machine: Log from machine with QEMU:
Well it's finding now, so there's clearly some other problem with addition to that. When I run it with I even get line numbers from inside : That line () is the last line in the following snippet of code: ... so is deliberately ing here due to . Grepping through the docs turns up: This is happening because uses . Once you do that, glibc needs to unwind the stack frame of any thread that calls . And unwinders are a giant headache. I'm afraid that's all I've got here. I've removed the closed-by from since it was only part of the problem here.
Ah, I think I know what it is. We can compile a without , but it won't have an unwinder. We need to pass the glibc headers to the build in order to get one of those.
would you please try ? I believe it fixes one of the two problems which caused this issue, and it includes which fixes the other one. It works for me: BTW, this issue (cross-compile , then run it under qemu) is a really valuable test case. We really ought to add it to so Hydra will catch any regressions automatically.


Question: !langJit && !stdenv.hostPlatform.isDarwin && enableShared <del> ; </del> <ins> ; </ins> <del> # For some reason libgcc_s.so has major-version "2" on m68k but # "1" everywhere else.  Might be worth changing this to "*". libgcc_s-version-major = if targetPlatform.isM68k then "2" else "1"; </del> <ins> # For some reason libgcc_s.so has major-version "2" on m68k but # "1" everywhere else.  Might be worth changing this to "*". libgcc_s-version-major = if targetPlatform.isM68k then "2" else "1"; </ins> in (pkg: pkg.overrideAttrs (previousAttrs: lib.optionalAttrs ((!langC) || langJit || enableLibGccOutput) {

Especially since the failure mode gives the user no error message to help them troubleshoot the problem! is a great candidate for this since it's one of those very rare non-C++ programs that uses advanced stack-unwinding features from pthreads.
Confirming fixes the issue. Tested with both and on real hardware and with QEMU on x86_64.
~I think this is fixed, and more cleanly,~ by Edit: it is not. :frowning_face: I will keep trying. Test is in Currently building.
Added this to , but commented out since it is not fixed yet.


Question: # Arguments that this derivation gets when it is created with `callPackage` { stdenv , lib <del> , symlinkJoin </del> , makeWrapper <ins> , symlinkJoin </ins> , yt-dlp }:

<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: mpv <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.33.1 desired version: 0.34.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.


Question: sed '2i echo Skipping rm deep-2 test && exit 77' -i ./tests/rm/deep-2.sh sed '2i echo Skipping du long-from-unreadable test && exit 77' -i ./tests/du/long-from-unreadable.sh <ins> # The test tends to fail on cephfs sed '2i echo Skipping df total-verify test && exit 77' -i ./tests/df/total-verify.sh </ins> # Some target platforms, especially when building inside a container have # issues with the inotify test. sed '2i echo Skipping tail inotify dir recreate test && exit 77' -i ./tests/tail/inotify-dir-recreate.sh

Steps to reproduce the behavior: error occurs is installed as a standalone binary. There is custom configuration: The test that fails is : I would, but it depends on coreutils. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Seems like a "known issue" without a solution with cephfs and that test: If you can use default path for store instead of: you won't have to build it yourself as it should be fetched from instead.
Unfortunately, I very much cannot use . Given that it's a known bug with that test, would a PR disabling that test likely be accepted into nixpkgs?
Maintainers for in nixpkgs would probably be able answer it better. But you can always overlay/add patch to your own config. Considering you are already building everything from scratch there won't be that much difference there.
Not sure why this wasn't auto closed.


Question: { lib , buildPythonPackage <ins> , fetchpatch </ins> , fetchPypi , isPy3k , pytestCheckHook

Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: -


Question: ./scripts/light-scrubber.sh ''; <ins> postInstall = '' mkdir -p $doc/share/doc/shogun/examples mv $out/share/shogun/examples/cpp $doc/share/doc/shogun/examples cp ../examples/undocumented/libshogun/*.cpp $doc/share/doc/shogun/examples/cpp rm -r $out/share ''; </ins> meta = with lib; { description = "A toolbox which offers a wide range of efficient and unified machine learning methods"; homepage = "http://shogun-toolbox.org/"; license = if withSvmLight then licenses.unfree else licenses.gpl3Plus; <del> maintainers = with maintainers; [ edwtjo ]; </del> <ins> maintainers = with maintainers; [ edwtjo smancill ]; </ins> }; }

shogun fails to build since the eigen 3.4.0 bump: The package is a likely candidate for removal. Upstream is unresponsive and development has halted. Removed from debian: Removed from fedora: Blocking vcpkg update: Please run and paste the result. Maintainer information:
I think you were the last one to modify this package, so please speak up if you need it. Also pinging Last call - if no one responds within the next week, I'll open a PR to remove this package.
Yes, I was working on making it build on Darwin and adding it as a Python 3 module. Well, I did, but I didn't feel motivated to create a PR. As you comment, upstream has been inactive for almost a year, the latest release is several years old, and it becomes harder and harder to make it work, and the patches would start to accumulate. To make it work on Darwin we need two upstream patches that fix the build with newer compiler versions. In the current derivation, the Python interface is not built because the CMake flag is not the right one. When enabled, Swig 3 is used to generate the Python interface, but Swig 3 doesn't support Python 3.8+ (and with Swig 4 just fails). It can be fixed with a patch, that feels more like a hack, intercepting the Makefile build, so I am not happy with it: Another small patch is needed to fix the deprecated . Also, I wasn't happy that adding it as a Python module will recompile the entire library again, which takes too much time IMO. I haven't checked if it is possible to build with Eigen 3.4 because it takes forever to compile. It could probably work on the development version. Note that the development version doesn't support Eigen 3.4 because of this, but it may work: But there is no such limitation on the 6.1.4 release, which probably means it would require another patch to fix the code, if somebody figures out. So, I'd argue that the package is too old now, and the derivation has too many issues, and it's too much of a hassle to maintain it, so it's probably better to just remove it.
I decided to sit and take a look at the error, and I actually fixed it.


Question: ./scripts/light-scrubber.sh ''; <ins> postInstall = '' mkdir -p $doc/share/doc/shogun/examples mv $out/share/shogun/examples/cpp $doc/share/doc/shogun/examples cp ../examples/undocumented/libshogun/*.cpp $doc/share/doc/shogun/examples/cpp rm -r $out/share ''; </ins> meta = with lib; { description = "A toolbox which offers a wide range of efficient and unified machine learning methods"; homepage = "http://shogun-toolbox.org/"; license = if withSvmLight then licenses.unfree else licenses.gpl3Plus; <del> maintainers = with maintainers; [ edwtjo ]; </del> <ins> maintainers = with maintainers; [ edwtjo smancill ]; </ins> }; }

I don't really use Eigen but the patch makes sense. So, I can send a PR to keep this package on the repo for another cycle at least. I mean, I already did all of the work and it builds. Other distros end up removing it because nobody cares to maintain it.
Nice! Thanks for looking into it. Like you said, if you've already done the work to get it working I don't see why not. If it's too much work to keep it working in the future we can always revisit this and drop it.


Question: <ins> --- old/build/pkgs/python3/spkg-install	2017-07-21 14:10:00.000000000 -0500 +++ new/build/pkgs/python3/spkg-install	2017-10-15 13:11:17.769261404 -0500 @@ -22,6 +22,9 @@ cd src +LDFLAGS="-lcrypt $LDFLAGS" +export LDFLAGS + if [ "$SAGE_DEBUG" = "yes" ]; then echo "Building Python with pydebug" PYTHON_CONFIGURE="$PYTHON_CONFIGURE --with-pydebug" </ins>

Since Sage is huge and complicated, I figured I would make this issue to collaboratively track progress and share branches. One big issue is that Sage 7 , instead they use some with scant documentation . has the correct SHA256 for Sage 7.6 and updates a patch file. It currently fails when Sage tries to build . Some nice things to do for the future: ) cc:
thanks for picking this up
Me myself being a miserable loser who has failed to update Sage in the past, I hope you succeed… My attempt hit the following wall. It is unbearably slow to let Sage build everything, but when I had convinced it to use the system versions of majority of dependencies it began to complain cryptically about their interaction in some case.
Can you elaborate? Do you have a branch that has that work? Also, to be clear: I probably don't have the skills or time to upgrade Sage by myself, I was hoping that if we shared our knowledge and de-duplicated efforts we might be able to get closer together
I think it was 6-dot-something; it required a metric ton of adding options to the packages in NixPkgs (I have pushed that all to master long ago), and the Sage tricks are most likely too version-specific. It was long enough ago that I have since abandoned and lost the changes.
In case anybody in here is still waiting for this: I got sage to compile and run. I'm currently trying to minimize the dependencies and check that everything is working correctly (there is one doctest failure, but it was mentioned multiple times in the mailing list and apperas to be harmles -- just a timeout). I'll probably make a PR in the next couple of days.


Question: <ins> --- old/build/pkgs/python3/spkg-install	2017-07-21 14:10:00.000000000 -0500 +++ new/build/pkgs/python3/spkg-install	2017-10-15 13:11:17.769261404 -0500 @@ -22,6 +22,9 @@ cd src +LDFLAGS="-lcrypt $LDFLAGS" +export LDFLAGS + if [ "$SAGE_DEBUG" = "yes" ]; then echo "Building Python with pydebug" PYTHON_CONFIGURE="$PYTHON_CONFIGURE --with-pydebug" </ins>

Sage needs texlive-core-2014, which is deprecated. Run with modern nixpkgs (i.e. from git) System: NixOS: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version:


Question: # }); libnix = dontCheck super.libnix; <del> # https://github.com/jmillikin/chell/issues/1 chell = super.chell.override { patience = self.patience_0_1_1; }; </del> # The test suite tries to mess with ALSA, which doesn't work in the build sandbox. xmobar = dontCheck super.xmobar;

The Haskell package chell does not build due to missing dependency . I think this the culprit: Try to get a nix-shell with purescript and nixpgks pinned to . Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(stefan): nixpkgs: (Note that this fails with a pinned nixpkg, see above.)


Question: <ins> { lib, stdenv, buildNpmPackage, fetchFromGitHub, makeWrapper, makeDesktopItem, copyDesktopItems, electron, httptoolkit-server, }: buildNpmPackage rec { pname = "httptoolkit"; version = "1.19.0"; src = fetchFromGitHub { owner = "httptoolkit"; repo = "httptoolkit-desktop"; rev = "refs/tags/v${version}"; hash = "sha256-e+ngBZMwMTvwzY1K7IaxlNoRkZUPDdJvKxvxuCsc9pw="; }; npmDepsHash = "sha256-XgJIs4P1ezCEPPitIIfYpNkX0/3dPdajeIiDwHm7DSU="; env = { ELECTRON_SKIP_BINARY_DOWNLOAD = "1"; # disable code signing on Darwin CSC_IDENTITY_AUTO_DISCOVERY = "false"; }; nativeBuildInputs = [ makeWrapper ] ++ lib.optionals stdenv.isLinux [ copyDesktopItems ]; npmBuildScript = "build:src"; postBuild = '' substituteInPlace package.json --replace-fail  '"forceCodeSigning": true'  '"forceCodeSigning": false' cp -r ${electron.dist} electron-dist chmod -R u+w electron-dist npm exec electron-builder --  --dir  -c.electronDist=electron-dist  -c.electronVersion=${electron.version} ''; installPhase = '' runHook preInstall ${lib.optionalString stdenv.isLinux '' mkdir -p $out/share/httptoolkit cp -r dist/*-unpacked/{locales,resources{,.pak}} $out/share/httptoolkit ln -s ${httptoolkit-server} $out/share/httptoolkit/resources/httptoolkit-server install -Dm644 src/icons/icon.svg $out/share/icons/hicolor/scalable/apps/httptoolkit.svg makeWrapper ${lib.getExe electron} $out/bin/httptoolkit  --add-flags $out/share/httptoolkit/resources/app.asar  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations}}"  --inherit-argv0 ''} ${lib.optionalString stdenv.isDarwin '' mkdir -p $out/Applications cp -r dist/mac*/"HTTP Toolkit.app" $out/Applications ln -s ${httptoolkit-server} "$out/Applications/HTTP Toolkit.app/Contents/Resources/httptoolkit-server" makeWrapper "$out/Applications/HTTP Toolkit.app/Contents/MacOS/HTTP Toolkit" $out/bin/httptoolkit ''} runHook postInstall ''; desktopItems = [ (makeDesktopItem { name = "httptoolkit"; desktopName = "HTTP Toolkit"; exec = "httptoolkit %U"; terminal = false; icon = "httptoolkit"; startupWMClass = "HTTP Toolkit"; comment = meta.description; categories = [ "Development" ]; startupNotify = true; }) ]; meta = { description = "HTTP(S) debugging, development & testing tool"; homepage = "https://httptoolkit.com/"; license = lib.licenses.agpl3Plus; mainProgram = "httptoolkit"; maintainers = with lib.maintainers; [ tomasajt ]; platforms = electron.meta.platforms; }; } </ins>

HTTP Toolkit is an open-source tool for debugging, testing and building with HTTP(S) on Windows, Linux & Mac. Metadata homepage URL: source URL: license: AGPL v3.0 platforms: linux, darwin
Sorry, wasn't able to get it working. The httptoolkit-server is the difficult part. I tried building from source, however one of the dependencies tries to npm install more stuff in prebuild, so it wasn't building properly. I tried packaging the prebuilt binary but it's trying to do some auto updating and also package node with itself. I could have patched this when building from source, however the prebuilt one is minified & obfuscated so I couldn't do that.
Have you a branch to continue the work ?
+1
I've started a small bounty of 20$ on this: It's not much but it would be great to have this tool on nix!
I made another attempt at packaging this and I'm pretty close to getting httptoolkit-server to compile from source. This should help with patching out stuff, since we can do it before it gets obfuscated.
if anyone needs to run this on nix the appimage provided by HttpToolkit works pretty well on nix with no extra dependencies. See and then Would still be great to have this as a nix package though.
Hey thanks for adding this! You can claim the gitpay bounty here: (I've tried to find your email to invite you but didn't have much luck) or email me at
Sent you an email,


Question: hash = "sha256-3fax57oaJvOgbTDPCiiUdtsfAGhICfPkuMihawq06SA="; }; <del> outputs = [ "out" "dev" ]; </del> <ins> outputs = [ "out" "dev" ]; </ins> strictDeps = true; nativeBuildInputs = [ cmake ninja pkg-config ]; buildInputs = [ libnice openssl


Question: rm $out/bin/slack makeWrapper $out/lib/slack/slack $out/bin/slack  --prefix XDG_DATA_DIRS : $GSETTINGS_SCHEMAS_PATH  <del> --prefix PATH : ${xdg-utils}/bin </del> <ins> --prefix PATH : ${lib.makeBinPath [xdg-utils]} </ins> # Fix the desktop link substituteInPlace $out/share/applications/slack.desktop

Describe the bug Starting slack doesn't show the window in 8 out of 10 runs To Reproduce Steps to reproduce the behavior: Expected behavior Slack window should open Screenshots If applicable, add screenshots to help explain your problem. 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 system: host os: multi-user?: sandbox: version: channels(ymatsiuk): channels(root): nixpkgs: Maintainer information:


Question: webSettingsJSON = pkgs.writeText "settings.json" (builtins.toJSON webSettings); # TODO: Should this be RFC42-ised so that users can set additional options without modifying the module? <del> mtaConfig = pkgs.writeText "mailman-postfix.cfg" '' </del> <ins> postfixMtaConfig = pkgs.writeText "mailman-postfix.cfg" '' </ins> [postfix] postmap_command: ${pkgs.postfix}/bin/postmap transport_file_type: hash

Describe the bug Mailman module in NixOS requires postfix enabled and has no way to configure Mailman to work with other MTAs supported by both NixOS and mailman upstream. To Reproduce Steps to reproduce the behavior: postfix mailman the evaluation with an assertion Expected behavior The Mailman module allows to select an MTA of choice (or even adapts to the currently enabled MTA) Screenshots n/a Additional context Notify maintainers cc Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(vika): nixpkgs: Maintainer information:
It looks like exim's configuration should be RFC42-ised first if we want to inject Mailman-related settings into Exim config, which is a requirement (Mailman requires a custom Exim router and transport).
Yes, the module is currently quite opinionated. If you're willing to contribute exim support that's great.
I see how I could make it work, but the first version of it will require manual editing of Exim's config files (because RFC42-ising Exim will be a pain, even though I have some drafts on how to translate Nix into the syntax that's required), and I'm not sure if it will be merge-worthy enough :3
Exim config is complicated enough as is, I'm not sure adding an intermediate layer from nix will help that much. I also don't really see this integrating well with existing or other exim config. I'm honestly kind of surprised this works for postfix.


Question: /nixos/modules/services/networking/babeld.nix @mweinelt /nixos/modules/services/networking/kea.nix @mweinelt /nixos/modules/services/networking/knot.nix @mweinelt <ins> nixos/modules/services/networking/networkmanager.nix @Janik-Haag </ins> /nixos/modules/services/monitoring/prometheus/exporters/kea.nix @mweinelt /nixos/tests/babeld.nix @mweinelt /nixos/tests/kea.nix @mweinelt /nixos/tests/knot.nix @mweinelt <ins> /nixos/tests/networking/* @Janik-Haag </ins> # Web servers /doc/packages/nginx.section.md @raitobezarius

Describe the bug NetworkManager is a particularly important component and we don't have any tests for it that could block a channel advance. In particular, a change can happen on nixos-unstable leaving users without functioning networking, and while rollbacks are possible it isn't an excuse to allow that to reach production systems. NixOS doesn't produce either. Manual testing is also cumbersome if we want to make a new stable release. Upstream NetworkManager does have some integration testing but obviously not useful to us. I think to start, if we at least had a test that verifies the services start without issues would be great.
Agreed. While developing tests for the multipath TCP module I was surprised to see no networkmanager module. I had some difficulties with the nixos test infrastructure at first because the test infra will by default install a slirp interface () and it messed up the interface naming. Like I would clear but interfaces would still be named starting from instead of . Just thought I would mention it in case the brave soul writing the test is interested in multihoming. (but that's more a concern I have with the test infra).
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
Bleh.
I marked this as stale due to inactivity. →
consequences of our inactions


Question: <ins> diff --git a/tests/test_climat2.py b/tests/test_climat2.py index cede642..2d5ad77 100644 --- a/tests/test_climat2.py +++ b/tests/test_climat2.py @@ -10,12 +10,7 @@ import glob from libmat2 import images, parser_factory -mat2_binary = ['./mat2'] - -if 'MAT2_GLOBAL_PATH_TESTSUITE' in os.environ: -    # Debian runs tests after installing the package -    # https://0xacab.org/jvoisin/mat2/issues/16#note_153878 -    mat2_binary = ['/usr/bin/env', 'mat2'] +mat2_binary = [os.environ['out'] + '/bin/mat2'] class TestHelp(unittest.TestCase): </ins>

Project description Metadata proposed package name: homepage source URL: license: platforms: probably portable to all platforms which Nix supports. requires python3, exiftool, gobject introspection


Question: if installed_version < available_version: print("updating systemd-boot from %s to %s" % (installed_version, available_version)) <del> subprocess.check_call(["@systemd@/bin/bootctl", "--esp-path=@efiSysMountPoint@", "update"]) </del> <ins> subprocess.check_call(["@systemd@/bin/bootctl", "--esp-path=@efiSysMountPoint@"] + bootctl_flags + ["update"]) </ins> os.makedirs("@efiSysMountPoint@/efi/nixos", exist_ok=True) os.makedirs("@efiSysMountPoint@/loader/entries", exist_ok=True)

During systemd-boot update step attempts to touch EFI variables, even when is set to . Steps to reproduce the behavior: NixOS 21.05 with systemd-boot and to NixOS 21.11 () switch fails with: An error is just an indication of update trying to touch EFI variables. (I have EFI vars touching disabled on that system because of some unrelated firmware breakage) Manually running properly finishes, further switches work fine. systemd-boot update should not touch EFI variables during upgrade. <!-- 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. Maintainer information:
I had a similar issue which I fixed by running "sudo nixos-rebuild --install-bootloader switch"
The fix for this got reverted in


Question: nativeBuildInputs = [ cmake nasm ]; buildInputs = [ <del> gtk2 glib ffmpeg_4 alsa-lib libmad libogg libvorbis glew libpulseaudio udev </del> <ins> alsa-lib ffmpeg_6 glew glib gtk2 libmad libogg libpulseaudio libvorbis udev xorg.libXtst </ins> ]; cmakeFlags = [

Describe the bug The menu icon for Stepmania is missing. To Reproduce Steps to reproduce the behavior: to find it in the Applications menu. Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I marked this as stale due to inactivity. →


Question: owner = "maxbachmann"; repo = "RapidFuzz"; rev = "refs/tags/v${version}"; <del> hash = "sha256-a83Vww9dEh0nNylnZwCm6PJYmfKvw5RnMLerfKfN1dY="; </del> <ins> hash = "sha256-hx8DNFxzD41tvxcKaSqqKkxJMlcrxAaihulUdkzyOt0="; </ins> }; nativeBuildInputs = [

Steps to reproduce the behavior: python3Packages.rapidfuzz Introduced in . Please run and paste the result.
It appears that cmake selects an incorrect linker. I am currently unsure what's the reason for this. Following I think I might need to set: I have zero experience with nix os + no access to a mac. Is there any way to patch in the build system here to check whether this solves the issue?


Question: }; lp_solve = callPackage ../applications/science/math/lp_solve { <del> inherit (darwin) cctools; </del> <ins> inherit (darwin) cctools autoSignDarwinBinariesHook; </ins> }; fabric-installer = callPackage ../tools/games/minecraft/fabric-installer { };

Steps to reproduce the behavior:
I don't have an M1 to test
Oh, it suffices to use . I'll open a pull request.


Question: with python.pkgs; buildPythonApplication rec { pname = "pdm"; <del> version = "2.10.4"; format = "pyproject"; disabled = pythonOlder "3.7"; </del> <ins> version = "2.12.1"; pyproject = true; disabled = pythonOlder "3.8"; </ins> src = fetchPypi { inherit pname version; <del> hash = "sha256-bf2dTLWQQ+3sstC0fSCOVdidMzunGX3rBcyi37x6S/s="; </del> <ins> hash = "sha256-OaKroZmGyUWnm/WEw3dSheJOnH+O2KYDgVthxfrF20w="; </ins> }; nativeBuildInputs = [

Steps to reproduce the behavior: truststore Output of : Adding to solves this issue. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: pwnat = callPackage ../tools/networking/pwnat { }; <del> pwndbg = python3Packages.callPackage ../development/tools/misc/pwndbg { }; </del> <ins> pwndbg = callPackage ../development/tools/misc/pwndbg { }; </ins> pycangjie = pythonPackages.pycangjie;

Describe the bug fails to run because setuptools is no longer propagated implictly. If were purely a python application built with then we would just need to add to propagatedBuildInputs and be done. However, is not simply a Python application, but a wrapper around , and isn't built using. The derivation patches the script as follows: This does result in the site-packages directories from all python packages ending up in , including setuptools (e.g. ). I'm not that familiar with Python packaging but from experimenting I found that the full path to the Python egg needs to be included (e.g. ) in order for this method to work. I made an attempt at resolving the issue but being new to Python packaging in Nix, neither are likely to be ideal: We could use buildPythonPackage in place of mkDerivation, using and use Or continue to use mkDerivation and manually set for patchPythonScript: I'm happy to submit a PR but I'm not sure what the recommended solution is here. To Reproduce Steps to reproduce the behavior: Expected behavior should launch with the extension loaded: Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
It seems is normally used by adding a to , or calling with (what the wrapper registered in does). This script then just does some addition calculations to register itself (we probably don't that at all) and some python 2 specific fixups, and then calls , which starts executing some code on import. I'd suggest to package it as a regular python application first (via ), so you can successfully import it inside a . The python tooling should automatically take care of patching the python shebang properly if you make script executable.
proposed fix


Question: <ins> diff --git a/actions/system/CMakeLists.txt b/actions/system/CMakeLists.txt index ca861145..3e3d3d3b 100644 --- a/actions/system/CMakeLists.txt +++ b/actions/system/CMakeLists.txt @@ -66,8 +66,6 @@ set(HEADERS ${HEADERS_PREFIX}/actions/playsoundinstance.hpp ${HEADERS_PREFIX}/actions/systemdefinition.hpp ${HEADERS_PREFIX}/actions/systeminstance.hpp -    ${HEADERS_PREFIX}/actions/texttospeechdefinition.hpp -    ${HEADERS_PREFIX}/actions/texttospeechinstance.hpp ${HEADERS_PREFIX}/code/mediaplaylist.hpp ${HEADERS_PREFIX}/code/notify.hpp ${HEADERS_PREFIX}/code/process.hpp @@ -131,7 +129,6 @@ find_package(Qt5 ${ACT_MINIMUM_QT_VERSION} COMPONENTS DBus Multimedia MultimediaWidgets -    TextToSpeech REQUIRED) target_include_directories(${PROJECT} @@ -153,7 +150,6 @@ target_link_libraries(${PROJECT} Qt5::DBus Qt5::Multimedia Qt5::MultimediaWidgets -    Qt5::TextToSpeech ${LIBNOTIFY_LIBRARIES} ${BLUEZ_LIBRARIES} ${UDEV_LIBRARIES} diff --git a/actions/system/src/actionpacksystem.hpp b/actions/system/src/actionpacksystem.hpp index c5768415..27a899d6 100644 --- a/actions/system/src/actionpacksystem.hpp +++ b/actions/system/src/actionpacksystem.hpp @@ -31,10 +31,6 @@ #include "actions/playsounddefinition.hpp" #include "actions/findimagedefinition.hpp" -#if QT_VERSION >= QT_VERSION_CHECK(5, 10, 0) -#include "actions/texttospeechdefinition.hpp" -#endif - #include "code/system.hpp" #include "code/mediaplaylist.hpp" #include "code/notify.hpp" @@ -67,9 +63,6 @@ public: addActionDefinition(new Actions::DetachedCommandDefinition(this)); addActionDefinition(new Actions::PlaySoundDefinition(this)); addActionDefinition(new Actions::FindImageDefinition(this)); -#if QT_VERSION >= QT_VERSION_CHECK(5, 10, 0) -        addActionDefinition(new Actions::TextToSpeechDefinition(this)); -#endif } QString id() const override							{ return QStringLiteral("system"); } </ins>

Project description mouse macro Actiona is a task automation tool. It allows you to create and execute action lists. You don't need to know any programming language to use it: its intuitive interface allows you to create action lists (scripts) using drag & drop. Advanced users can use JavaScript (EcmaScript) to extend its functionality. Actiona is free software and runs under Windows and GNU/Linux. Binaries are available for Windows and Ubuntu for both 32 and 64 bits. The program is developed in C++ and uses the Qt framework. Metadata homepage URL: source URL: license: gpl3 platforms: cross-platform
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .


Question: <ins> Patch included in advisory @ https://subversion.apache.org/security/CVE-2020-17525-advisory.txt --- a/subversion/libsvn_repos/config_file.c +++ b/subversion/libsvn_repos/config_file.c @@ -237,6 +237,10 @@ get_repos_config(svn_stream_t **stream, { /* Search for a repository in the full path. */ repos_root_dirent = svn_repos_find_root_path(dirent, scratch_pool); +      if (repos_root_dirent == NULL) +        return svn_error_trace(handle_missing_file(stream, checksum, access, +                                                   url, must_exist, +                                                   svn_node_none)); /* Attempt to open a repository at repos_root_dirent. */ SVN_ERR(svn_repos_open3(&access->repos, repos_root_dirent, NULL, </ins>

, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc


Question: fetch --distdir=${distDir} build --copt="$(echo $NIX_CFLAGS_COMPILE | sed -e 's/ /" --copt="/g')" build --host_copt="$(echo $NIX_CFLAGS_COMPILE | sed -e 's/ /" --host_copt="/g')" <ins> build --linkopt="$(echo $(< ${stdenv.cc}/nix-support/libcxx-ldflags) | sed -e 's/ /" --linkopt="/g')" build --host_linkopt="$(echo $(< ${stdenv.cc}/nix-support/libcxx-ldflags) | sed -e 's/ /" --host_linkopt="/g')" </ins> build --linkopt="-Wl,$(echo $NIX_LDFLAGS | sed -e 's/ /" --linkopt="-Wl,/g')" build --host_linkopt="-Wl,$(echo $NIX_LDFLAGS | sed -e 's/ /" --host_linkopt="-Wl,/g')" build --host_javabase='@local_jdk//:jdk'

Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify 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. Maintainer information:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in


Question: pdfjam = callPackage ../tools/typesetting/pdfjam { }; <ins> jbig2enc = callPackage ../tools/graphics/jbig2enc { }; </ins> pdfread = callPackage ../tools/graphics/pdfread { }; briss = callPackage ../tools/graphics/briss { };

Unfortunately I can not pinpoint the issue, but it seems that after a on Feb 1st, starts to omit a key file out of 3 key files and completely fails with a fresh system installation. Steps to reproduce the behavior: .nix contains the following lines All three files exist on disk. -rebuild switch produces a initrd-secret archive that is missing the third key file. system installation produces the following: All key files are included in generated initrd-secrets and does not fail. This issue does not exist before system update. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --This option is declared in <nixpkgs/nixos/modules/system/boot/stage-1.nix. Please run and paste the result.
I specifically installed an encrypted root on zfs system with . GRUB will decrypt disk on boot and initrd will re-decrypt disk partitions and swap with the keys embedded here.
I have that too, there seem to be a problem with here: Not sure where it is set from, but its value should be relative to the chroot, e.g. , not . It can be worked around by setting to an existing directory before installing/rebuilding, for example: Or by preparing a directory with yourself:
May be a duplicate of
Duplicate of indeed.


Question: <ins> { lib, stdenvNoLibs, buildPackages , gcc, glibc , libiberty }: let gccConfigureFlags = gcc.cc.configureFlags ++ [ "--disable-fixincludes" "--disable-intl" "--enable-threads=posix" "--with-glibc-version=${glibc.version}" # these are required in order to prevent inhibit_libc=true, # which will cripple libgcc's unwinder; see: #  https://github.com/NixOS/nixpkgs/issues/213453#issuecomment-1616346163 "--with-headers=${lib.getDev glibc}/include" "--with-native-system-header-dir=${lib.getDev glibc}${glibc.incdir or "/include"}" "--with-build-sysroot=/" ]; in stdenvNoLibs.mkDerivation (finalAttrs: { pname = "libgcc"; inherit (gcc.cc) src version; outputs = [ "out" "dev" ]; strictDeps = true; depsBuildBuild = [ buildPackages.stdenv.cc ]; nativeBuildInputs = [ libiberty ]; buildInputs = [ glibc ]; postUnpack = '' mkdir -p ./build buildRoot=$(readlink -e "./build") ''; postPatch = gcc.cc.passthru.forceLibgccToBuildCrtStuff + '' sourceRoot=$(readlink -e "./libgcc") ''; hardeningDisable = [ "pie" ]; preConfigure = '' # Drop in libiberty, as external builds are not expected cd "$buildRoot" ( mkdir -p build-${stdenvNoLibs.buildPlatform.config}/libiberty/ cd build-${stdenvNoLibs.buildPlatform.config}/libiberty/ ln -s ${buildPackages.libiberty}/lib/libiberty.a ./ ) mkdir -p "$buildRoot/gcc" cd "$buildRoot/gcc" ( # We "shift" the tools over to fake platforms perspective from the previous stage. export AS_FOR_BUILD=${buildPackages.stdenv.cc}/bin/$AS_FOR_BUILD export CC_FOR_BUILD=${buildPackages.stdenv.cc}/bin/$CC_FOR_BUILD export CPP_FOR_BUILD=${buildPackages.stdenv.cc}/bin/$CPP_FOR_BUILD export CXX_FOR_BUILD=${buildPackages.stdenv.cc}/bin/$CXX_FOR_BUILD export LD_FOR_BUILD=${buildPackages.stdenv.cc.bintools}/bin/$LD_FOR_BUILD export AS=$AS_FOR_BUILD export CC=$CC_FOR_BUILD export CPP=$CPP_FOR_BUILD export CXX=$CXX_FOR_BUILD export LD=$LD_FOR_BUILD export AS_FOR_TARGET=${stdenvNoLibs.cc}/bin/$AS export CC_FOR_TARGET=${stdenvNoLibs.cc}/bin/$CC export CPP_FOR_TARGET=${stdenvNoLibs.cc}/bin/$CPP export LD_FOR_TARGET=${stdenvNoLibs.cc.bintools}/bin/$LD # We define GENERATOR_FILE so nothing bothers looking for GNU GMP. export NIX_CFLAGS_COMPILE_FOR_BUILD+=' -DGENERATOR_FILE=1' "$sourceRoot/../gcc/configure" ${lib.concatStringsSep " " gccConfigureFlags} # We remove the `libgcc.mvar` deps so that the bootstrap xgcc isn't built. sed -e 's,libgcc.mvars:.*$,libgcc.mvars:,' -i Makefile make  config.h  libgcc.mvars  tconfig.h  tm.h  options.h  insn-constants.h  insn-modes.h ) mkdir -p "$buildRoot/gcc/include" # Preparing to configure + build libgcc itself mkdir -p "$buildRoot/gcc/${stdenvNoLibs.hostPlatform.config}/libgcc" cd "$buildRoot/gcc/${stdenvNoLibs.hostPlatform.config}/libgcc" configureScript=$sourceRoot/configure chmod +x "$configureScript" export AS_FOR_BUILD=${buildPackages.stdenv.cc}/bin/$AS_FOR_BUILD export CC_FOR_BUILD=${buildPackages.stdenv.cc}/bin/$CC_FOR_BUILD export CPP_FOR_BUILD=${buildPackages.stdenv.cc}/bin/$CPP_FOR_BUILD export CXX_FOR_BUILD=${buildPackages.stdenv.cc}/bin/$CXX_FOR_BUILD export LD_FOR_BUILD=${buildPackages.stdenv.cc.bintools}/bin/$LD_FOR_BUILD export AS=${stdenvNoLibs.cc}/bin/$AS export CC=${stdenvNoLibs.cc}/bin/$CC export CPP=${stdenvNoLibs.cc}/bin/$CPP export CXX=${stdenvNoLibs.cc}/bin/$CXX export LD=${stdenvNoLibs.cc.bintools}/bin/$LD export AS_FOR_TARGET=${stdenvNoLibs.cc}/bin/$AS_FOR_TARGET export CC_FOR_TARGET=${stdenvNoLibs.cc}/bin/$CC_FOR_TARGET export CPP_FOR_TARGET=${stdenvNoLibs.cc}/bin/$CPP_FOR_TARGET export LD_FOR_TARGET=${stdenvNoLibs.cc.bintools}/bin/$LD_FOR_TARGET ''; configurePlatforms = [ "build" "host" ]; configureFlags = [ "cross_compiling=true" "--disable-gcov" "--with-glibc-version=${glibc.version}" ]; makeFlags = [ "MULTIBUILDTOP:=../" ]; postInstall = '' moveToOutput "lib/gcc/${stdenvNoLibs.hostPlatform.config}/${finalAttrs.version}/include" "$dev" mkdir -p "$out/lib" "$dev/include" ln -s "$out/lib/gcc/${stdenvNoLibs.hostPlatform.config}/${finalAttrs.version}"/* "$out/lib" ln -s "$dev/lib/gcc/${stdenvNoLibs.hostPlatform.config}/${finalAttrs.version}/include"/* "$dev/include/" ''; }) </ins>

On or cross-compiled from , breaks: From : You can either run this on another architecture using . or should not crash: This was responsible for failing to replicate datasets to my ARM NAS. The issue does not_ occur for natively compiled builds. It appears to be a cross-compilation issue only.
It is a bug in / derivations. In non-cross cases it gets copied from used to bid into output: But in cross-case used to build does not yet provide as it needs bits of for it (and the library path is slightly incorrect). One of possible workarounds is to try to add to to get it pulled via from expected location.
We don't do the copying to glibc anymore, but this error still occurs as described on current nixpkgs master.
Yup. cross-compilation never propagated to in any form (and does not today).
Could you please try this PR? It should fix the problem.
With that PR, I'm seeing this on both (a Raspberry Pi CM4) and with QEMU on : Log from aarch64 machine: Log from machine with QEMU:
Well it's finding now, so there's clearly some other problem with addition to that. When I run it with I even get line numbers from inside : That line () is the last line in the following snippet of code: ... so is deliberately ing here due to . Grepping through the docs turns up: This is happening because uses . Once you do that, glibc needs to unwind the stack frame of any thread that calls . And unwinders are a giant headache. I'm afraid that's all I've got here. I've removed the closed-by from since it was only part of the problem here.
Ah, I think I know what it is. We can compile a without , but it won't have an unwinder. We need to pass the glibc headers to the build in order to get one of those.
would you please try ? I believe it fixes one of the two problems which caused this issue, and it includes which fixes the other one. It works for me: BTW, this issue (cross-compile , then run it under qemu) is a really valuable test case. We really ought to add it to so Hydra will catch any regressions automatically.


Question: <ins> { lib, stdenvNoLibs, buildPackages , gcc, glibc , libiberty }: let gccConfigureFlags = gcc.cc.configureFlags ++ [ "--disable-fixincludes" "--disable-intl" "--enable-threads=posix" "--with-glibc-version=${glibc.version}" # these are required in order to prevent inhibit_libc=true, # which will cripple libgcc's unwinder; see: #  https://github.com/NixOS/nixpkgs/issues/213453#issuecomment-1616346163 "--with-headers=${lib.getDev glibc}/include" "--with-native-system-header-dir=${lib.getDev glibc}${glibc.incdir or "/include"}" "--with-build-sysroot=/" ]; in stdenvNoLibs.mkDerivation (finalAttrs: { pname = "libgcc"; inherit (gcc.cc) src version; outputs = [ "out" "dev" ]; strictDeps = true; depsBuildBuild = [ buildPackages.stdenv.cc ]; nativeBuildInputs = [ libiberty ]; buildInputs = [ glibc ]; postUnpack = '' mkdir -p ./build buildRoot=$(readlink -e "./build") ''; postPatch = gcc.cc.passthru.forceLibgccToBuildCrtStuff + '' sourceRoot=$(readlink -e "./libgcc") ''; hardeningDisable = [ "pie" ]; preConfigure = '' # Drop in libiberty, as external builds are not expected cd "$buildRoot" ( mkdir -p build-${stdenvNoLibs.buildPlatform.config}/libiberty/ cd build-${stdenvNoLibs.buildPlatform.config}/libiberty/ ln -s ${buildPackages.libiberty}/lib/libiberty.a ./ ) mkdir -p "$buildRoot/gcc" cd "$buildRoot/gcc" ( # We "shift" the tools over to fake platforms perspective from the previous stage. export AS_FOR_BUILD=${buildPackages.stdenv.cc}/bin/$AS_FOR_BUILD export CC_FOR_BUILD=${buildPackages.stdenv.cc}/bin/$CC_FOR_BUILD export CPP_FOR_BUILD=${buildPackages.stdenv.cc}/bin/$CPP_FOR_BUILD export CXX_FOR_BUILD=${buildPackages.stdenv.cc}/bin/$CXX_FOR_BUILD export LD_FOR_BUILD=${buildPackages.stdenv.cc.bintools}/bin/$LD_FOR_BUILD export AS=$AS_FOR_BUILD export CC=$CC_FOR_BUILD export CPP=$CPP_FOR_BUILD export CXX=$CXX_FOR_BUILD export LD=$LD_FOR_BUILD export AS_FOR_TARGET=${stdenvNoLibs.cc}/bin/$AS export CC_FOR_TARGET=${stdenvNoLibs.cc}/bin/$CC export CPP_FOR_TARGET=${stdenvNoLibs.cc}/bin/$CPP export LD_FOR_TARGET=${stdenvNoLibs.cc.bintools}/bin/$LD # We define GENERATOR_FILE so nothing bothers looking for GNU GMP. export NIX_CFLAGS_COMPILE_FOR_BUILD+=' -DGENERATOR_FILE=1' "$sourceRoot/../gcc/configure" ${lib.concatStringsSep " " gccConfigureFlags} # We remove the `libgcc.mvar` deps so that the bootstrap xgcc isn't built. sed -e 's,libgcc.mvars:.*$,libgcc.mvars:,' -i Makefile make  config.h  libgcc.mvars  tconfig.h  tm.h  options.h  insn-constants.h  insn-modes.h ) mkdir -p "$buildRoot/gcc/include" # Preparing to configure + build libgcc itself mkdir -p "$buildRoot/gcc/${stdenvNoLibs.hostPlatform.config}/libgcc" cd "$buildRoot/gcc/${stdenvNoLibs.hostPlatform.config}/libgcc" configureScript=$sourceRoot/configure chmod +x "$configureScript" export AS_FOR_BUILD=${buildPackages.stdenv.cc}/bin/$AS_FOR_BUILD export CC_FOR_BUILD=${buildPackages.stdenv.cc}/bin/$CC_FOR_BUILD export CPP_FOR_BUILD=${buildPackages.stdenv.cc}/bin/$CPP_FOR_BUILD export CXX_FOR_BUILD=${buildPackages.stdenv.cc}/bin/$CXX_FOR_BUILD export LD_FOR_BUILD=${buildPackages.stdenv.cc.bintools}/bin/$LD_FOR_BUILD export AS=${stdenvNoLibs.cc}/bin/$AS export CC=${stdenvNoLibs.cc}/bin/$CC export CPP=${stdenvNoLibs.cc}/bin/$CPP export CXX=${stdenvNoLibs.cc}/bin/$CXX export LD=${stdenvNoLibs.cc.bintools}/bin/$LD export AS_FOR_TARGET=${stdenvNoLibs.cc}/bin/$AS_FOR_TARGET export CC_FOR_TARGET=${stdenvNoLibs.cc}/bin/$CC_FOR_TARGET export CPP_FOR_TARGET=${stdenvNoLibs.cc}/bin/$CPP_FOR_TARGET export LD_FOR_TARGET=${stdenvNoLibs.cc.bintools}/bin/$LD_FOR_TARGET ''; configurePlatforms = [ "build" "host" ]; configureFlags = [ "cross_compiling=true" "--disable-gcov" "--with-glibc-version=${glibc.version}" ]; makeFlags = [ "MULTIBUILDTOP:=../" ]; postInstall = '' moveToOutput "lib/gcc/${stdenvNoLibs.hostPlatform.config}/${finalAttrs.version}/include" "$dev" mkdir -p "$out/lib" "$dev/include" ln -s "$out/lib/gcc/${stdenvNoLibs.hostPlatform.config}/${finalAttrs.version}"/* "$out/lib" ln -s "$dev/lib/gcc/${stdenvNoLibs.hostPlatform.config}/${finalAttrs.version}/include"/* "$dev/include/" ''; }) </ins>

Especially since the failure mode gives the user no error message to help them troubleshoot the problem! is a great candidate for this since it's one of those very rare non-C++ programs that uses advanced stack-unwinding features from pthreads.
Confirming fixes the issue. Tested with both and on real hardware and with QEMU on x86_64.
~I think this is fixed, and more cleanly,~ by Edit: it is not. :frowning_face: I will keep trying. Test is in Currently building.
Added this to , but commented out since it is not fixed yet.


Question: <del> { lib, stdenv, fetchFromGitHub, cmake, pkg-config, gtk3, ncurses , libcpuid, pciutils, procps, wrapGAppsHook3, nasm, makeWrapper , opencl-headers, ocl-icd , vulkan-headers, vulkan-loader, glfw , libXdmcp, pcre, util-linux , libselinux, libsepol , libthai, libdatrie, libxkbcommon, libepoxy , dbus, at-spi2-core , libXtst </del> <ins> { lib, testers, stdenv, fetchFromGitHub, cmake, pkg-config, gtk3, ncurses, libcpuid, pciutils, procps, wrapGAppsHook3, nasm, opencl-headers, ocl-icd, vulkan-headers, vulkan-loader, glfw, libXdmcp, pcre, util-linux, libselinux, libsepol, libthai, libdatrie, libxkbcommon, libepoxy, dbus, at-spi2-core, libXtst, gtkmm3, </ins> }: # Known issues:

When trying to start the App from the launcher, nothing happens. In the terminal starts the text based version, but typing throws the following error =Source: Also check: And this is my system: !


Question: <del> { lib, stdenv, afl}: stdenv.mkDerivation { version = lib.getVersion afl; pname = "libdislocator"; src = afl.src; sourceRoot = "${afl.src.name}/libdislocator"; makeFlags = [ "PREFIX=$(out)" ]; preInstall = '' mkdir -p $out/lib/afl ''; postInstall = '' mkdir $out/bin cat > $out/bin/get-libdislocator-so <<END #!${stdenv.shell} echo $out/lib/afl/libdislocator.so END chmod +x $out/bin/get-libdislocator-so ''; meta = with lib; { homepage = "https://lcamtuf.coredump.cx/afl/"; description = '' Drop-in replacement for the libc allocator which improves the odds of bumping into heap-related security bugs in several ways. ''; mainProgram = "get-libdislocator-so"; license = lib.licenses.asl20; maintainers = with maintainers; [ ris ]; }; } </del>

Steps to reproduce the behavior: afl <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
If you are planing to open a PR, you don't need to create an issue first.
I wasn't sure, thanks for clarification


Question: <ins> #!/usr/bin/env nix-shell #!nix-shell -i bash -p curl gnused jq set -x -eu -o pipefail cd $(dirname "${BASH_SOURCE[0]}") VERSION_JSON=$(curl --silent https://cef-builds.spotifycdn.com/index.json | jq '[.linux64.versions[] | select (.channel == "stable")][0]') CEF_VERSION=$(echo ${VERSION_JSON} | jq -r '.cef_version' | cut -d'+' -f1) GIT_REVISION=$(echo ${VERSION_JSON} | jq -r '.cef_version' | cut -d'+' -f2 | cut -c 2-) CHROMIUM_VERSION=$(echo ${VERSION_JSON} | jq -r '.chromium_version') SHA256_LINUX64=$(nix-prefetch-url --quiet https://cef-builds.spotifycdn.com/cef_binary_${CEF_VERSION}+g${GIT_REVISION}+chromium-${CHROMIUM_VERSION}_linux64_minimal.tar.bz2) SHA256_LINUX32=$(nix-prefetch-url --quiet https://cef-builds.spotifycdn.com/cef_binary_${CEF_VERSION}+g${GIT_REVISION}+chromium-${CHROMIUM_VERSION}_linux32_minimal.tar.bz2) SHA256_LINUXARM64=$(nix-prefetch-url --quiet https://cef-builds.spotifycdn.com/cef_binary_${CEF_VERSION}+g${GIT_REVISION}+chromium-${CHROMIUM_VERSION}_linuxarm64_minimal.tar.bz2) setKV () { sed -i "s|$1 = ".*"|$1 = "${2:-}"|" ./default.nix } setKV version ${CEF_VERSION} setKV gitRevision ${GIT_REVISION} setKV chromiumVersion ${CHROMIUM_VERSION} setKV 'platforms."aarch64-linux".sha256' ${SHA256_LINUXARM64} setKV 'platforms."i686-linux".sha256' ${SHA256_LINUX32} setKV 'platforms."x86_64-linux".sha256' ${SHA256_LINUX64} </ins>

I just filed a to update our version of CEF to fix a . The previous version was released on 2019-07-27— that's almost 2 years! For a piece of software that's functionally a web browser, we certainly shouldn't be using an out-of-date version: web browsers have a massive attack surface and it's very important to keep them updated at all times. I don't have the time to work on this right at the moment, but it shouldn't be too difficult. There's a containing metadata for every CEF release. All that should be necessary is to grab the latest stable version for the right platform. While we're at it, we could also consider building for i686 and AArch64. Tagging the maintainer
IDK how it works, but it sounds like a job for the bot ().


Question: propagatedBuildInputs = [ six protobuf ] ++ lib.optionals (isPy27) [ enum34 futures ]; <del> preBuild = lib.optionalString stdenv.isDarwin "unset AR"; </del> <ins> preBuild = '' export GRPC_PYTHON_BUILD_EXT_COMPILER_JOBS="$NIX_BUILD_CORES" if [ -z "$enableParallelBuilding" ]; then GRPC_PYTHON_BUILD_EXT_COMPILER_JOBS=1 fi '' + lib.optionalString stdenv.isDarwin '' unset AR ''; </ins> GRPC_BUILD_WITH_BORING_SSL_ASM = ""; GRPC_PYTHON_BUILD_SYSTEM_OPENSSL = 1;

Building uses more () threads than it should (i.e. 2 if / ). Steps to reproduce the behavior: as the build will use way more than 2 cores. Build should honour properly. This was with . This does not in fact use just 1 thread. :smilingfacewith_tear:. ! Happens on master () and 22.11.
I don't have any time planned to fix this but if you figure it out please send a PR.


Question: buildInputs = [ flex bison pkgconfig ]; <ins> configureFlags = ["EXTENSION_DIR=$(out)/lib/php/extensions"]; </ins> flags = { # much left to do here...

I ran into a problem when trying to install PHP + PECL extensions (via package). When PHP compiles, it installs extensions configured during build into a default directory like which differs for each PHP version and compile configurations (like ZTS support). When installing PECL extensions via ontop of PHP, they are installed into a fixed directory which makes it impossible to load those via (without knowing the absolute path) as PHP expects them to find in . In scenarios where you define your outside of nix context, it is impossible to load the PECL extensions. I wonder if a consistent extension directory for both PHP and PECL extensions could be established. Maybe the PHP package could set the (see ) environment variable to before like it is done in the . That would make it much easier to configure PHP extensions. See my profile to get an impression: /cc


Question: , newStdcpp ? false }: <del> buildFHSUserEnv { name = "steam"; </del> <ins> let self = { name = "steam"; </ins> <del> targetPkgs = pkgs: with pkgs; [ </del> <ins> targetPkgs = pkgs: with pkgs; [ </ins> steamPackages.steam steamPackages.steam-fonts # License agreement

This weekend I tried these games, all deadlocked in the menu or character selection. Nyheim Oh...Sir! The Insult Simulator Reigns Unturned (free to play) You don't have to be worried to waste money in case you want to test a game. I have had no problem when requesting refunds, just go to I have played these games and found no issues with them: Dota 2 Counter-Strike TIS-100 World of goo Faster Than Light You Must Build a Boat Risk of Rain System: (NixOS: , Ubuntu/Fedora: , ...) 03pre99759. (Gorilla) Nix version: (run ) nix-env (Nix) 1.11.6 Nixpkgs version: (run ) "17.03pre99759." Integrated graphics card, 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
This is normal with steam on nixos unfortunately. There are many steam games that don't work for various reasons, unfortunately many linux steam game developers only make sure their games run on ubuntu and don't really care about relying only on dependencies from the steam runtime. Some games don't play nice with certain graphics cards or drivers as well. If you want to get a particular game working (I can list 150 games that work under nixos with nvidia card and drivers at least) then you'll need to do some work, or at least post any relevant logs from the game/steam so people can actually help you solve the problem. That is assuming that they own the game. :)
There's a slowly-growing list of extra dependencies in the Steam package. If you can figure out what's missing, you can add it there; e.g. as in
I don't have enough motivation to actually buy games for the sole purpose of fixing them and then refunding, sorry. Nevertheless, I'm happy to help if you can post logs and/or s -- those two are the most helpful for determining FHS-related problems.


Question: shotcut = libsForQt5.callPackage ../applications/video/shotcut { }; shogun = callPackage ../applications/science/machine-learning/shogun { <del> stdenv = gcc8Stdenv; # Workaround for the glibc abi version mismatch. # Please note that opencv builds are by default disabled. opencv = opencv3.override { stdenv = gcc8Stdenv; openexr = openexr.override { stdenv = gcc8Stdenv; }; }; </del> <ins> opencv = opencv3; </ins> }; smplayer = libsForQt5.callPackage ../applications/video/smplayer { };

shogun fails to build since the eigen 3.4.0 bump: The package is a likely candidate for removal. Upstream is unresponsive and development has halted. Removed from debian: Removed from fedora: Blocking vcpkg update: Please run and paste the result. Maintainer information:
I think you were the last one to modify this package, so please speak up if you need it. Also pinging Last call - if no one responds within the next week, I'll open a PR to remove this package.
Yes, I was working on making it build on Darwin and adding it as a Python 3 module. Well, I did, but I didn't feel motivated to create a PR. As you comment, upstream has been inactive for almost a year, the latest release is several years old, and it becomes harder and harder to make it work, and the patches would start to accumulate. To make it work on Darwin we need two upstream patches that fix the build with newer compiler versions. In the current derivation, the Python interface is not built because the CMake flag is not the right one. When enabled, Swig 3 is used to generate the Python interface, but Swig 3 doesn't support Python 3.8+ (and with Swig 4 just fails). It can be fixed with a patch, that feels more like a hack, intercepting the Makefile build, so I am not happy with it: Another small patch is needed to fix the deprecated . Also, I wasn't happy that adding it as a Python module will recompile the entire library again, which takes too much time IMO. I haven't checked if it is possible to build with Eigen 3.4 because it takes forever to compile. It could probably work on the development version. Note that the development version doesn't support Eigen 3.4 because of this, but it may work: But there is no such limitation on the 6.1.4 release, which probably means it would require another patch to fix the code, if somebody figures out. So, I'd argue that the package is too old now, and the derivation has too many issues, and it's too much of a hassle to maintain it, so it's probably better to just remove it.
I decided to sit and take a look at the error, and I actually fixed it.


Question: shotcut = libsForQt5.callPackage ../applications/video/shotcut { }; shogun = callPackage ../applications/science/machine-learning/shogun { <del> stdenv = gcc8Stdenv; # Workaround for the glibc abi version mismatch. # Please note that opencv builds are by default disabled. opencv = opencv3.override { stdenv = gcc8Stdenv; openexr = openexr.override { stdenv = gcc8Stdenv; }; }; </del> <ins> opencv = opencv3; </ins> }; smplayer = libsForQt5.callPackage ../applications/video/smplayer { };

I don't really use Eigen but the patch makes sense. So, I can send a PR to keep this package on the repo for another cycle at least. I mean, I already did all of the work and it builds. Other distros end up removing it because nobody cares to maintain it.
Nice! Thanks for looking into it. Like you said, if you've already done the work to get it working I don't see why not. If it's too much work to keep it working in the future we can always revisit this and drop it.


Question: </para> </listitem> </varlistentry> <del> <varlistentry> </del> <ins> <varlistentry xml:id="var-passthru-updateScript"> </ins> <term> <varname>passthru.updateScript</varname> </term>

I just found out about wrapGAppsHook by examining a gnome package, but there really should be documentation about this in the Nixpkgs User Guide (a section about Gnome would be nice, which would show the right way to package GTK3 / GTK2 glib based apps). Also, perhaps there are other things I missed that one should know when packaging Gnome Applications or GTK3/2 apps? /cc Gnome maintainers
I'd like to know as well. Currently receiving this error: On one of the packages I'm trying to put into nixpkgs. Apparently sometimes you need for buildInputs. So apparently all you need to do to use this is:
The error occurs when you do not have any directory containing in variable. One of the things does is (which usually contains the aforementioned file) of dependencies to . (Actually this happens in cooperation with via variable.) Icon themes work in the same vein, only is used and it is populated by which is propagated to (). (XDG fallback theme) should be probably to any GTK application that uses icons (I think that is every GTK applicaton nowadays due to CSD) but some applications require Adwaita because they use icons not in hicolor. Not sure if this functions correctly though, at least it should not according to my mental model of how icon theme selection works; I will need to read the relevant XDG spec before I can finish the documentation.
Just thought I'd leave this comment here for future reference: if you get an error like for python gtk applications, try adding to propogatedBuildInputs!
It should go to , though. But be wary of


Question: homepage = "https://tu-dresden.de/zih/forschung/projekte/firestarter"; description = "Processor Stress Test Utility"; platforms = platforms.linux; <del> maintainers = with maintainers; [ astro ]; </del> <ins> maintainers = with maintainers; [ astro marenz ]; </ins> license = licenses.gpl3; }; }

Describe the bug I don't know if we should just update it or not. To Reproduce Steps to reproduce the behavior: on master Expected behavior Screenshots Additional context Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(bbigras): channels(root): nixpkgs: Maintainer information:
I can reproduce the issue locally It used to build previously The current is not in the Hydra cache because was never built by Hydra, so, unless someone else has the , we can't compare Upstream tag doesn't appear to be updated, git repo doesn't use export-subst It is not clear to me what has happened here.
Dear all, the tag v1.7.4 has been changed after October 2019. It was not published for long as it involuntarily got into a commit. There have been no public releases for v1.7.4 marked on Github or our the FIRESTARTER Website as of October 2019.
Thanks everyone for the help. :heart:


Question: neorg = buildVimPluginFrom2Nix { pname = "neorg"; <del> version = "2022-03-27"; </del> <ins> version = "2022-03-26"; </ins> src = fetchFromGitHub { owner = "nvim-neorg"; repo = "neorg"; <del> rev = "168c17fa9373fe5e4927fe59acf448e2c531132a"; sha256 = "1ad6wx8wi7mc28vbkl1zz72z7yy6x6mk9rfnkxdhwpwddmqpg6v0"; </del> <ins> rev = "8f8c1ae889ffe666423a89271933272ebffec3ef"; sha256 = "10fgkrr9wn6jj35qa42c353k4rnys9a2wrckjk0kwrx6kvx7m6l6"; </ins> }; meta.homepage = "https://github.com/nvim-neorg/neorg/"; };

Project description Various vim plugins iamcco/coc-tailwindcss coc-extensions/coc-svelte evanleck/vim-svelte


Question: stdenv.mkDerivation rec { pname = "clipboard-jh"; <del> version = "0.8.3"; </del> <ins> version = "0.9.0.1"; </ins> src = fetchFromGitHub { owner = "Slackadays"; repo = "clipboard"; rev = version; <del> hash = "sha256-G0zOr56dR9rmymQ9MwPNnMZ2LZuuz4NiswRQIvdS9MY="; </del> <ins> hash = "sha256-iILtyURYCshicgAV3MWkgMQsXHe7Unj1A08W7tUMU2o="; </ins> }; postPatch = ''

Package name: clipboard-jh Latest released version: 0.9.0 <!-- Search your package here: --- Current version on the unstable channel: 0.8.3 Current version on the stable/release channel: 0.8.3 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: do makeWrapper "$out/share/neo4j/bin/$NEO4J_SCRIPT"  "$out/bin/$NEO4J_SCRIPT"  <del> --prefix PATH : "${lib.makeBinPath [ jre8 which gawk ]}"  --set JAVA_HOME "$jre8" </del> <ins> --prefix PATH : "${lib.makeBinPath [ jre which gawk ]}"  --set JAVA_HOME "${jre}" </ins> done '';

Describe the bug Neo4j does not start because it cannot locate a Java Runtime. To Reproduce On my system, I installed with: Then, running shows: "The operation couldn’t be completed. Unable to locate a Java Runtime." Expected behavior Neo4j should start. Additional context Note that shows Note the line that sets to . 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. Maintainer information:


Question: <del> --- old/build/pkgs/python2/spkg-install	2015-07-26 15:34:43.000000000 +0200 +++ new/build/pkgs/python2/spkg-install	2015-09-16 20:48:51.904555797 +0200 @@ -32,7 +32,7 @@ done # We are setting LDFLAGS so that we pick up Sage's readline -LDFLAGS="-L$SAGE_LOCAL/lib $LDFLAGS" +LDFLAGS="-L$SAGE_LOCAL/lib -lcrypt $LDFLAGS" export LDFLAGS if [ "$SAGE_DEBUG" = "yes" ]; then </del>

Since Sage is huge and complicated, I figured I would make this issue to collaboratively track progress and share branches. One big issue is that Sage 7 , instead they use some with scant documentation . has the correct SHA256 for Sage 7.6 and updates a patch file. It currently fails when Sage tries to build . Some nice things to do for the future: ) cc:
thanks for picking this up
Me myself being a miserable loser who has failed to update Sage in the past, I hope you succeed… My attempt hit the following wall. It is unbearably slow to let Sage build everything, but when I had convinced it to use the system versions of majority of dependencies it began to complain cryptically about their interaction in some case.
Can you elaborate? Do you have a branch that has that work? Also, to be clear: I probably don't have the skills or time to upgrade Sage by myself, I was hoping that if we shared our knowledge and de-duplicated efforts we might be able to get closer together
I think it was 6-dot-something; it required a metric ton of adding options to the packages in NixPkgs (I have pushed that all to master long ago), and the Sage tricks are most likely too version-specific. It was long enough ago that I have since abandoned and lost the changes.
In case anybody in here is still waiting for this: I got sage to compile and run. I'm currently trying to minimize the dependencies and check that everything is working correctly (there is one doctest failure, but it was mentioned multiple times in the mailing list and apperas to be harmles -- just a timeout). I'll probably make a PR in the next couple of days.


Question: <del> --- old/build/pkgs/python2/spkg-install	2015-07-26 15:34:43.000000000 +0200 +++ new/build/pkgs/python2/spkg-install	2015-09-16 20:48:51.904555797 +0200 @@ -32,7 +32,7 @@ done # We are setting LDFLAGS so that we pick up Sage's readline -LDFLAGS="-L$SAGE_LOCAL/lib $LDFLAGS" +LDFLAGS="-L$SAGE_LOCAL/lib -lcrypt $LDFLAGS" export LDFLAGS if [ "$SAGE_DEBUG" = "yes" ]; then </del>

Sage needs texlive-core-2014, which is deprecated. Run with modern nixpkgs (i.e. from git) System: NixOS: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version:


Question: <del> { lib , stdenv , cmake , llvm , fetchFromGitHub , mbedtls , gtk3 , pkg-config , capstone , dbus , libGLU , glfw3 , file , perl , python3 , jansson , curl , fmt_8 , nlohmann_json , yara , rsync </del> <ins> { lib, stdenv, cmake, llvm, fetchFromGitHub, mbedtls, gtk3, pkg-config, capstone, dbus, libGLU, libGL, glfw3, file, perl, python3, jansson, curl, fmt_8, nlohmann_json, yara, rsync, autoPatchelfHook, </ins> }: let <del> version = "1.33.2"; patterns_version = "1.33.2"; </del> <ins> version = "1.35.3"; patterns_version = "1.35.3"; </ins> patterns_src = fetchFromGitHub { <ins> name = "ImHex-Patterns-source-${patterns_version}"; </ins> owner = "WerWolv"; repo = "ImHex-Patterns"; rev = "ImHex-v${patterns_version}"; <del> hash = "sha256-5a6aFT8R8vMzPS+Y+fcDV5+olhioEpLjdMqa7qOyGsw="; </del> <ins> hash = "sha256-h86qoFMSP9ehsXJXOccUK9Mfqe+DVObfSRT4TCtK0rY="; </ins> }; in

Imhex on unstable and nixos-24.05 crashes. Output from the above command: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same as pending to merge
Ah, sorry, I only searched in opened issues.


Question: <del> { lib , stdenv , cmake , llvm , fetchFromGitHub , mbedtls , gtk3 , pkg-config , capstone , dbus , libGLU , glfw3 , file , perl , python3 , jansson , curl , fmt_8 , nlohmann_json , yara , rsync </del> <ins> { lib, stdenv, cmake, llvm, fetchFromGitHub, mbedtls, gtk3, pkg-config, capstone, dbus, libGLU, libGL, glfw3, file, perl, python3, jansson, curl, fmt_8, nlohmann_json, yara, rsync, autoPatchelfHook, </ins> }: let <del> version = "1.33.2"; patterns_version = "1.33.2"; </del> <ins> version = "1.35.3"; patterns_version = "1.35.3"; </ins> patterns_src = fetchFromGitHub { <ins> name = "ImHex-Patterns-source-${patterns_version}"; </ins> owner = "WerWolv"; repo = "ImHex-Patterns"; rev = "ImHex-v${patterns_version}"; <del> hash = "sha256-5a6aFT8R8vMzPS+Y+fcDV5+olhioEpLjdMqa7qOyGsw="; </del> <ins> hash = "sha256-h86qoFMSP9ehsXJXOccUK9Mfqe+DVObfSRT4TCtK0rY="; </ins> }; in

Imhex failed to start. Steps to reproduce the behavior: -shell -p imhex --run imhex Shows the following errors: Imhex start up normally. Adding -v, --verbose doesn't give more information. I don't know how to either.
Maintainer ping:
Can repro on master, but can't repro if I checkout and build from it, it should be possible to bisect and find out at what point this broke.
First bad commit: <details<summarygit bisect log</summary</details
Seems there's a bunch of upstream reports of breakage with glfw 3.4
This might be fixed with The PR was merged into 1.90.6, but 1.33.2 contains a vendored 1.90.4, which doesn't contain the fix. My guess is that updating from the current 1.33.2 in nixpkgs to the latest version upstream (1.35.3 as of today) should fix the issue, as the latter contains a vendored updated to version 1.90.8, which should contain the fix.
Looks like the PR was closed, are you talking about instead?
Yes, sorry. I got the PR reference from: ... which also references the commit you mentioned.
Still crashes on imhex 1.35.3, which I more or less expected.
After applying both PRs and , finally works on my system with the current . Note: both PRs were needed, either one alone didn't fix all the issues for me.
Solved, marking as closed.


Question: <ins> { lib , buildPythonPackage , btrfs-progs }: buildPythonPackage { pname = "btrfsutil"; inherit (btrfs-progs) version src; format = "setuptools"; buildInputs = [ btrfs-progs ]; preConfigure = '' cd libbtrfsutil/python ''; # No tests doCheck = false; pythonImportsCheck = [ "btrfsutil" ]; meta = with lib; { description = "Library for managing Btrfs filesystems"; homepage = "https://btrfs.wiki.kernel.org/"; license = licenses.lgpl21Plus; maintainers = with maintainers; [ raskin lopsided98 ]; }; } </ins>

Python module, corresponding to the package and exposing its functionality in Python programs, fails to import, despite being included in . module is imported successfully. n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- (as maintainer) (as the one who exposed the Python bindings) Please run and paste the result.
Note: it seems like the module doesn't work even on commits that introduced it properly... To verify, run in a Nixpkgs checkout:
Yeah, I screwed up testing this. btrfs-progs doesn't propagate python, so I was using my system (non-NixOS) Python installation without noticing. should fix it.


Question: (fetchNuGet { pname = "System.Net.Http"; version = "4.3.0"; sha256 = "1i4gc757xqrzflbk7kc5ksn20kwwfjhw9w7pgdkn19y3cgnl302j"; }) (fetchNuGet { pname = "System.Net.NameResolution"; version = "4.3.0"; sha256 = "15r75pwc0rm3vvwsn8rvm2krf929mjfwliv0mpicjnii24470rkq"; }) (fetchNuGet { pname = "System.Net.Primitives"; version = "4.3.0"; sha256 = "0c87k50rmdgmxx7df2khd9qj7q35j9rzdmm2572cc55dygmdk3ii"; }) <del> (fetchNuGet { pname = "System.Net.Security"; version = "4.3.2"; sha256 = "1aw1ca1vssqrillrh4qkarx0lxwc8wcaqdkfdima8376wb98j2q8"; }) </del> <ins> (fetchNuGet { pname = "System.Net.Security"; version = "4.3.0"; sha256 = "1aa5igz31ivk6kpgsrwck3jccab7wd88wr52lddmgypmbh9mmf87"; }) </ins> (fetchNuGet { pname = "System.Net.Sockets"; version = "4.3.0"; sha256 = "1ssa65k6chcgi6mfmzrznvqaxk8jp0gvl77xhf1hbzakjnpxspla"; }) (fetchNuGet { pname = "System.Net.WebHeaderCollection"; version = "4.3.0"; sha256 = "0ms3ddjv1wn8sqa5qchm245f3vzzif6l6fx5k92klqpn7zf4z562"; }) (fetchNuGet { pname = "System.Net.WebSockets"; version = "4.3.0"; sha256 = "1gfj800078kggcgl0xyl00a6y5k4wwh2k2qm69rjy22wbmq7fy4p"; })

Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: nativeBuildInputs = [ pkgconfig ]; buildInputs = [ <del> curl </del> <ins> curl zlib </ins> ] ++ stdenv.lib.optionals stdenv.isDarwin [ CoreServices Security ]; cargoBuildFlags = [ "--features no-self-update" ]; patches = lib.optionals stdenv.isLinux [ <del> (runCommand "0001-dynamically-patchelf-binaries.patch" { CC=stdenv.cc; patchelf = patchelf; } '' </del> <ins> (let libPath = lib.makeLibraryPath [ zlib # libz.so.1 ]; in (runCommand "0001-dynamically-patchelf-binaries.patch" { CC=stdenv.cc; patchelf = patchelf; libPath = "$ORIGIN/../lib:${libPath}"; } '' </ins> export dynamicLinker=$(cat $CC/nix-support/dynamic-linker) substitute ${./0001-dynamically-patchelf-binaries.patch} $out  --subst-var patchelf  <del> --subst-var dynamicLinker </del> <ins> --subst-var dynamicLinker  --subst-var libPath </ins> '') <ins> ) </ins> ]; doCheck = !stdenv.isAarch64 && !stdenv.isDarwin;

Describe the bug As of rust nightly 2020-06-22, Rust nightly cannot find This issue is not present in Rust nightly 2020-06-21. To Reproduce Steps to reproduce the behavior: Expected behavior rustc works Additional context This also happens with rust nightly from Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(jade): nixpkgs: Maintainer information:
We are currently using in internally to set the elf interpreter. Looks like we need to extend this to also extend the RPATH to add zlib. If someone makes a PR, I will review it! Not sure when I would get to implement that myself.
Here is where we add :
I'm working on a patch for this. This is definitely the issue, just need to find the right way to extend the RPATH. I have something replacing it with a path containing zlib, but that overwrites the existing , which breaks it. I would like to verify what is setting there but hardcoding it should provide an early fix
Extending the RPATH seems not to have worked
I'm investigating patching the files in lib This issue may have been introduced by rust-lang/rust so it's likely the new zlib dependency shows up in the LLVM libraries


Question: "4.14": { "patch": { "extra": "-hardened1", <del> "name": "linux-hardened-4.14.328-hardened1.patch", "sha256": "1qq2l4nwhxgl4drx6isc1ly892kffjq4hqb4zadqs6sxvsdm7x57", "url": "https://github.com/anthraxx/linux-hardened/releases/download/4.14.328-hardened1/linux-hardened-4.14.328-hardened1.patch" </del> <ins> "name": "linux-hardened-4.14.332-hardened1.patch", "sha256": "1nda3z8hkyfw53dzk1v5zwpzhm75gizsixfmrh8ylaghhk5s8yw3", "url": "https://github.com/anthraxx/linux-hardened/releases/download/4.14.332-hardened1/linux-hardened-4.14.332-hardened1.patch" </ins> }, <del> "sha256": "1igcpvnhwwrczfdsafmszvi0456k7f6j4cgpfw6v6afw09p95d8x", "version": "4.14.328" </del> <ins> "sha256": "1f4q0acbp917myjmgiy4haxp78yak5h1rj5g937r6mkykwb6nb14", "version": "4.14.332" </ins> }, "4.19": { "patch": { "extra": "-hardened1", <del> "name": "linux-hardened-4.19.297-hardened1.patch", "sha256": "1qj09bynl7ml880xpc2956jn0b1gmm77yf3jc45v3jq3610jhna4", "url": "https://github.com/anthraxx/linux-hardened/releases/download/4.19.297-hardened1/linux-hardened-4.19.297-hardened1.patch" </del> <ins> "name": "linux-hardened-4.19.301-hardened1.patch", "sha256": "0arlwp0g4anqlnivyc8y6rq9mhq1ivmy4i0d8kqvwpc2b3wcc525", "url": "https://github.com/anthraxx/linux-hardened/releases/download/4.19.301-hardened1/linux-hardened-4.19.301-hardened1.patch" </ins> }, <del> "sha256": "0c9xxqgv2i36hrr06dwz7f3idc04xpv0a5pxg08xdh03cnyf12cx", "version": "4.19.297" </del> <ins> "sha256": "1fr05fl8fyyjgsqj8fppd5v378d7sazvpqlq4sl875851fd9nmb2", "version": "4.19.301" </ins> }, "5.10": { "patch": { "extra": "-hardened1", <del> "name": "linux-hardened-5.10.199-hardened1.patch", "sha256": "10vwd5wygfnxpbz15bq56pjygba3vqqal0d7xry2bch4p444pp5f", "url": "https://github.com/anthraxx/linux-hardened/releases/download/5.10.199-hardened1/linux-hardened-5.10.199-hardened1.patch" </del> <ins> "name": "linux-hardened-5.10.203-hardened1.patch", "sha256": "19inx95ynyzhh2h9xdg2yw4yfa5nfcw2dh2a7vw4mf0bqdv2iqvc", "url": "https://github.com/anthraxx/linux-hardened/releases/download/5.10.203-hardened1/linux-hardened-5.10.203-hardened1.patch" </ins> }, <del> "sha256": "1h944syk7n6c4j1djlx19n77alzwbxcdza77c9ykicgfynhpgsm0", "version": "5.10.199" </del> <ins> "sha256": "0xr8p7kfr1v3s41fv55ph0l8d9s2p146dl2fh3r2y09lrvwwxssn", "version": "5.10.203" </ins> }, "5.15": { "patch": { "extra": "-hardened1", <del> "name": "linux-hardened-5.15.137-hardened1.patch", "sha256": "19gs1w380qgvazwjwhxypizpfx71faa7hsji0x5cgyw6vxhi6l1b", "url": "https://github.com/anthraxx/linux-hardened/releases/download/5.15.137-hardened1/linux-hardened-5.15.137-hardened1.patch" </del> <ins> "name": "linux-hardened-5.15.142-hardened1.patch", "sha256": "0x4bsf638rrdrp9b389i6nlprwsfc25qpld50yfcjinqhiykd269", "url": "https://github.com/anthraxx/linux-hardened/releases/download/5.15.142-hardened1/linux-hardened-5.15.142-hardened1.patch" </ins> }, <del> "sha256": "1xxjbxldrhmnh2q6rykpxyfbj8xqgl82q30n8sfavrzr14bb4jcp", "version": "5.15.137" </del> <ins> "sha256": "0xjn16b02f8d6c0m8vrbmk85kdyfy8m46s80rnkb0nnwfx9cjxld", "version": "5.15.142" </ins> }, "5.4": { "patch": { "extra": "-hardened1", <del> "name": "linux-hardened-5.4.259-hardened1.patch", "sha256": "1w8ipflgisd127gmx6wyz8p5qfi8cfd2a5j2xgibspkf45nzfwi8", "url": "https://github.com/anthraxx/linux-hardened/releases/download/5.4.259-hardened1/linux-hardened-5.4.259-hardened1.patch" </del> <ins> "name": "linux-hardened-5.4.263-hardened1.patch", "sha256": "1v59qzjp9v78y7fkj884a77pjsk4ggplkfh1fq2blj04g7v1zhgv", "url": "https://github.com/anthraxx/linux-hardened/releases/download/5.4.263-hardened1/linux-hardened-5.4.263-hardened1.patch" </ins> }, <del> "sha256": "195v4fidavzm637glj6580006mrcaygnbj4za874imb62bxf9rpz", "version": "5.4.259" </del> <ins> "sha256": "1y1mfwjsilrx8x8jnjlyh8r9zlygjjqdf7pay92jv2qijjddpl2h", "version": "5.4.263" </ins> }, "6.1": { "patch": { "extra": "-hardened1", <del> "name": "linux-hardened-6.1.61-hardened1.patch", "sha256": "0d9zhh32dx1q828q50kmznmsa6yinppbklhgg8ix7b7k23857ha6", "url": "https://github.com/anthraxx/linux-hardened/releases/download/6.1.61-hardened1/linux-hardened-6.1.61-hardened1.patch" </del> <ins> "name": "linux-hardened-6.1.67-hardened1.patch", "sha256": "0jcn2k79l90dys4nrwqha89jv9d1ffghhvlqk9vibfs7y3zrlpbr", "url": "https://github.com/anthraxx/linux-hardened/releases/download/6.1.67-hardened1/linux-hardened-6.1.67-hardened1.patch" </ins> }, <del> "sha256": "1kk4d7ph6pvgdrdmaklg15wf58nw9n7yqgkag7jdvqinzh99sb5d", "version": "6.1.61" </del> <ins> "sha256": "11cjqll3b7iq3mblwyzjrd5ph8avgk23f4mw4shm8j6ai5rdndvm", "version": "6.1.67" </ins> }, <del> "6.4": { </del> <ins> "6.5": { </ins> "patch": { "extra": "-hardened1", <del> "name": "linux-hardened-6.4.16-hardened1.patch", "sha256": "10lydnnhhq9ynng1gfaqh1mncsb0dmr27zzcbygs1xigy2bl70n9", "url": "https://github.com/anthraxx/linux-hardened/releases/download/6.4.16-hardened1/linux-hardened-6.4.16-hardened1.patch" </del> <ins> "name": "linux-hardened-6.5.13-hardened1.patch", "sha256": "1fj6yaq2gdjlj2h19vkm13jrx0yiczj6pvric1kq1r6cprqrkkki", "url": "https://github.com/anthraxx/linux-hardened/releases/download/6.5.13-hardened1/linux-hardened-6.5.13-hardened1.patch" </ins> }, <del> "sha256": "0zgj1z97jyx7wf12zrnlcp0mj4cl43ais9qsy6dh1jwylf2fq9ln", "version": "6.4.16" </del> <ins> "sha256": "1dfbbydmayfj9npx3z0g38p574pmcx3qgs49dv0npigl48wd9yvq", "version": "6.5.13" </ins> }, <del> "6.5": { </del> <ins> "6.6": { </ins> "patch": { "extra": "-hardened1", <del> "name": "linux-hardened-6.5.10-hardened1.patch", "sha256": "0p2lj7ryiizr1sxvm2kgds3l8sg9fns35y2fcyqq61lg7ymzj1fi", "url": "https://github.com/anthraxx/linux-hardened/releases/download/6.5.10-hardened1/linux-hardened-6.5.10-hardened1.patch" </del> <ins> "name": "linux-hardened-6.6.6-hardened1.patch", "sha256": "0jhhixayka13rb0cd0qbsqpb7awayjdbn8qyx7wya1y83cgyn2ly", "url": "https://github.com/anthraxx/linux-hardened/releases/download/6.6.6-hardened1/linux-hardened-6.6.6-hardened1.patch" </ins> }, <del> "sha256": "12sswml8jvabv6bqx35lg3jj6gq8jjk365rghjngdy5d0j34jpx1", "version": "6.5.10" </del> <ins> "sha256": "1j14n8b012pv3r7i9p762jyabzn2nv1ranxyw5lk3c9lg68hmxzb", "version": "6.6.6" </ins> } }

Project description Hardened patchset got released for Linux 6.6. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi, created the following merge request. Would appreciate a review.
will try to check that tomorrow's morning if my ibs allows me to, thanks


Question: let <del> inherit (lib) lists strings trivial; </del> <ins> inherit (lib) getLib lists strings trivial; </ins> inherit (magmaRelease) version hash supportedGpuTargets; # Per https://icl.utk.edu/magma/downloads, support for CUDA 12 wasn't added until 2.7.1.

tests link to , however is not explicitly included in of . This issue is normally hidden, because (for example) links to and so it is brought along as a transitive dependency of . However, may not always be set to . For example, doesn't link to . As a consequence, applying the following overlay and attempting to build results in the following errors: does list in its , however actually refers to that only includes the wrapped compiler binaries. If my understanding is correct, is provided by instead. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: owner = "Rosettea"; repo = "Hilbish"; rev = "v${version}"; <del> sha256 = "sha256-n4+qUCbjqxLmGuCQ0QTscJ3me0UZUP/7ggvGp1pNkfg="; </del> <ins> sha256 = "sha256-fUGeQM+7FRGTRL3J4c2+c+NTwrM6d99F2ucKsou2kRk="; </ins> fetchSubmodules = true; };

name: hilbish I guess? dunno how to use current version: 1.0.4 desired version: maintainers: Please tag this issue in your PR. I tried to update it myself: But that's not enough to get it to build and I have no experience with Golang stuff: Also: This is outdated. , and the releases have pre-compiled builds for both of them as well: !


Question: version = "111.0.1"; src = fetchurl { url = "mirror://mozilla/firefox/releases/${version}/source/firefox-${version}.source.tar.xz"; <del> sha512 = "e7d248b845cb524efc28818e0a0cad06ba5acac30219886191b702b61314388d10a1690c6d704b0a70d2bc2c4b1f04ed02350dcb9dce9c56503d2af3baefe4d3"; </del> <ins> sha512 = "b16c9399a19cb1de2d865a023d54fbe71c23a363ea4d36cd58f41f64f7ad04bc1b9d8a8448943417516e17337e0ee2afd370c29a72b51b0947161f4ffab6935f"; </ins> }; meta = {

Steps to reproduce the behavior: firefox-unwrapped from master branch Please run and paste the result.
The hash listed in has apparently changed at 16:36 UTC today. The tarball was already available earlier than that, so the release apparently changed later that day. That would also line up with the hash you are seeing. ` In fact, we have the same hash as e.g. . Will investigate the change shortly, then update the hash.


Question: , hunspellDicts, spellcheckerLanguage ? null # E.g. "de_DE" # For a full list of available languages: # $ cat pkgs/development/libraries/hunspell/dictionaries.nix | grep "dictFileName =" | awk '{ print $3 }' <ins> , python3 , gnome , sqlcipher </ins> }: let

Describe the bug Just lost on two different NixOS machine my Signal Desktop history because of this faulty update... I don't know, probably doesn't make sense for people to downgrade who are already upgraded but for others it dataloss To Reproduce Steps to reproduce the behavior: Signal Desktop Signal Desktop you to delete db, if you interact in a wrong way it will delete your data Notify maintainers ( and
Sorry to hear that. I recently lost my history too... It's really frustrating! Yeah, unfortunately I don't think there's anything we can do about it (as downstream package maintainers). AFAIK the source of the bug is still unknown, it doesn't seem to affect all users, and all releases have a limited lifetime ("expire" 90 days after the release, see my comment in ). Thanks for saying that! This really bothered me too... I just didn't say anything because I was too angry to keep it nice enough. (I raged a bit here but after I realized that one cannot even import old backups I had to take a break.)
I just got hit by a similar issue by moving from Archlinux (encrypted database) to NixOS (non encrypted database). After many things, the easiest fix to ensure proper functionalities IMHO is installing: This will disable tracker3 and prevent SQLite to be loaded in the process which will replace SQLCipher and cause the SQLite3 API to be the original one (i.e. non-encrypted) and cause many issues down the road I guess. That might not fix everything though :upsidedownface: Opened a PR:
FYI, in case anyone has feedback/suggestions: We might merge soon and it should cause another "Database startup error: Error: SQLITE_NOTADB: file is not a database" error (which is really unfortunate but not easily avoidable).
Heads-up: I've just merged to hopefully resolve this once and for all and the Python wrapper script should take care of the database re-encryption when launching Signal-Desktop as usual but the user experience isn't that great and you probably want to backup first in case the script fails unexpectedly.
Thank you, I just upgraded Signal on my computer and the re-encryption did work as intended


Question: "${config.boot.initrd.systemd.package}/lib/systemd/systemd-vconsole-setup" "${config.boot.initrd.systemd.package.kbd}/bin/setfont" "${config.boot.initrd.systemd.package.kbd}/bin/loadkeys" <del> "${config.boot.initrd.systemd.package.kbd.gzip}/bin/gzip" # keyboard layouts are compressed </del> <ins> "${config.boot.initrd.systemd.package.kbd.gzip}/bin/gzip" # Fonts and keyboard layouts are compressed ] ++ optionals (hasPrefix builtins.storeDir cfg.font) [ "${cfg.font}" ] ++ optionals (hasPrefix builtins.storeDir cfg.keyMap) [ "${cfg.keyMap}" </ins> ]; systemd.services.reload-systemd-vconsole-setup =

With and , I still have to type my LUKS passphrase in qwerty. The logs say this: but not much else apparently. The vconsole is set up fine by the time I get a login prompt.
Dup of


Question: "${config.boot.initrd.systemd.package}/lib/systemd/systemd-vconsole-setup" "${config.boot.initrd.systemd.package.kbd}/bin/setfont" "${config.boot.initrd.systemd.package.kbd}/bin/loadkeys" <del> "${config.boot.initrd.systemd.package.kbd.gzip}/bin/gzip" # keyboard layouts are compressed </del> <ins> "${config.boot.initrd.systemd.package.kbd.gzip}/bin/gzip" # Fonts and keyboard layouts are compressed ] ++ optionals (hasPrefix builtins.storeDir cfg.font) [ "${cfg.font}" ] ++ optionals (hasPrefix builtins.storeDir cfg.keyMap) [ "${cfg.keyMap}" </ins> ]; systemd.services.reload-systemd-vconsole-setup =

The option, which enables by default on high-resolution displays like my 4K laptop screen, is supposed to set the console font within the initrd before displaying the LUKS password prompt. However, with , this does not happen until stage 2, so the prompt is tiny. Enable , , and . The console font should be switched before the LUKS password prompt, not after.
Relevant code is probably that it sets . should then properly set everything up if it can find its files in :
Does it work when you do ?
No, it can’t, because points to a font file that’s not present in the initrd.
This works though. It’s a little jarring in that the font is changed about a second before the framebuffer resolution is changed, so it’s temporarily huge. Ideally those would happen simultaneously. But at least they both happen in time for the LUKS prompt.


Question: , wrapGAppsHook }: <del> let rpath = lib.makeLibraryPath [ alsaLib at-spi2-atk at-spi2-core atk cairo cups dbus expat fontconfig freetype gdk_pixbuf glib gnome2.GConf gtk3 libX11 libXScrnSaver libXcomposite libXcursor libXdamage libXext libXfixes libXi libXrandr libXrender libXtst libuuid nspr nss pango udev xdg_utils xorg.libxcb zlib </del> <ins> let rpath = lib.makeLibraryPath [ alsaLib at-spi2-atk at-spi2-core atk cairo cups dbus expat fontconfig freetype gdk_pixbuf glib gnome2.GConf gtk3 libX11 libXScrnSaver libXcomposite libXcursor libXdamage libXext libXfixes libXi libXrandr libXrender libXtst libuuid nspr nss pango udev xdg_utils xorg.libxcb zlib </ins> ]; <ins> in </ins> <del> in stdenv.mkDerivation rec { pname = "brave"; version = "0.61.50"; </del> <ins> stdenv.mkDerivation rec { pname = "brave"; version = "0.65.118"; </ins> <del> src = fetchurl { url = "https://github.com/brave/brave-browser/releases/download/v${version}/brave-browser_${version}_amd64.deb"; sha256 = "1lbajxnxqkd422rckfjm65pwwzl66v7anq4jrzxi29d5x7abl3c1"; }; </del> <ins> src = fetchurl { url = "https://github.com/brave/brave-browser/releases/download/v${version}/brave-browser_${version}_amd64.deb"; sha256 = "13bihzf4yfgn01nrw780swhmcdh8gq71jqilhbi04jn1h1pbm3wg"; }; </ins> <del> dontConfigure = true; dontBuild = true; dontPatchELF = true; </del> <ins> dontConfigure = true; dontBuild = true; dontPatchELF = true; </ins> <del> nativeBuildInputs = [ dpkg wrapGAppsHook ]; </del> <ins> nativeBuildInputs = [ dpkg wrapGAppsHook ]; </ins> <del> buildInputs = [ glib gnome3.gsettings_desktop_schemas gnome3.adwaita-icon-theme ]; </del> <ins> buildInputs = [ glib gsettings-desktop-schemas gnome3.adwaita-icon-theme ]; </ins> <del> unpackPhase = "dpkg-deb --fsys-tarfile $src | tar -x --no-same-permissions --no-same-owner"; </del> <ins> unpackPhase = "dpkg-deb --fsys-tarfile $src | tar -x --no-same-permissions --no-same-owner"; </ins> <del> installPhase = '' mkdir -p $out $out/bin </del> <ins> installPhase = '' mkdir -p $out $out/bin </ins> <del> cp -R usr/share $out cp -R opt/ $out/opt </del> <ins> cp -R usr/share $out cp -R opt/ $out/opt </ins> <del> export BINARYWRAPPER=$out/opt/brave.com/brave/brave-browser </del> <ins> export BINARYWRAPPER=$out/opt/brave.com/brave/brave-browser </ins> <del> # Fix path to bash in $BINARYWRAPPER substituteInPlace $BINARYWRAPPER  --replace /bin/bash ${stdenv.shell} </del> <ins> # Fix path to bash in $BINARYWRAPPER substituteInPlace $BINARYWRAPPER  --replace /bin/bash ${stdenv.shell} </ins> <del> ln -sf $BINARYWRAPPER $out/bin/brave </del> <ins> ln -sf $BINARYWRAPPER $out/bin/brave </ins> <del> patchelf  --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"  --set-rpath "${rpath}" $out/opt/brave.com/brave/brave </del> <ins> patchelf  --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"  --set-rpath "${rpath}" $out/opt/brave.com/brave/brave </ins> <del> # Fix paths substituteInPlace $out/share/applications/brave-browser.desktop  --replace /usr/bin/brave-browser $out/bin/brave substituteInPlace $out/share/gnome-control-center/default-apps/brave-browser.xml  --replace /opt/brave.com $out/opt/brave.com substituteInPlace $out/share/menu/brave-browser.menu  --replace /opt/brave.com $out/opt/brave.com substituteInPlace $out/opt/brave.com/brave/default-app-block  --replace /opt/brave.com $out/opt/brave.com </del> <ins> # Fix paths substituteInPlace $out/share/applications/brave-browser.desktop  --replace /usr/bin/brave-browser $out/bin/brave substituteInPlace $out/share/gnome-control-center/default-apps/brave-browser.xml  --replace /opt/brave.com $out/opt/brave.com substituteInPlace $out/share/menu/brave-browser.menu  --replace /opt/brave.com $out/opt/brave.com substituteInPlace $out/opt/brave.com/brave/default-app-block  --replace /opt/brave.com $out/opt/brave.com </ins> <del> # Correct icons location icon_sizes=("16" "22" "24" "32" "48" "64" "128" "256") </del> <ins> # Correct icons location icon_sizes=("16" "22" "24" "32" "48" "64" "128" "256") </ins> <del> for icon in ''${icon_sizes[*]} do mkdir -p $out/share/icons/hicolor/$iconx$icon/apps ln -s $out/opt/brave.com/brave/product_logo_$icon.png $out/share/icons/hicolor/$iconx$icon/apps/brave-browser.png done </del> <ins> for icon in ''${icon_sizes[*]} do mkdir -p $out/share/icons/hicolor/$iconx$icon/apps ln -s $out/opt/brave.com/brave/product_logo_$icon.png $out/share/icons/hicolor/$iconx$icon/apps/brave-browser.png done </ins> <del> # Replace xdg-settings and xdg-mime ln -sf ${xdg_utils}/bin/xdg-settings $out/opt/brave.com/brave/xdg-settings ln -sf ${xdg_utils}/bin/xdg-mime $out/opt/brave.com/brave/xdg-mime ''; </del> <ins> # Replace xdg-settings and xdg-mime ln -sf ${xdg_utils}/bin/xdg-settings $out/opt/brave.com/brave/xdg-settings ln -sf ${xdg_utils}/bin/xdg-mime $out/opt/brave.com/brave/xdg-mime ''; </ins> <del> meta = with stdenv.lib; { homepage = "https://brave.com/"; description = "Privacy-oriented browser for Desktop and Laptop computers"; longDescription = '' Brave browser blocks the ads and trackers that slow you down, chew up your bandwidth, and invade your privacy. Brave lets you contribute to your favorite creators automatically. ''; license = licenses.mpl20; maintainers = [ maintainers.uskudnik ]; platforms = [ "x86_64-linux" ]; }; </del> <ins> meta = with stdenv.lib; { homepage = "https://brave.com/"; description = "Privacy-oriented browser for Desktop and Laptop computers"; changelog = "https://github.com/brave/brave-browser/blob/v${version}/CHANGELOG.md"; longDescription = '' Brave browser blocks the ads and trackers that slow you down, chew up your bandwidth, and invade your privacy. Brave lets you contribute to your favorite creators automatically. ''; license = licenses.mpl20; maintainers = [ maintainers.uskudnik ]; platforms = [ "x86_64-linux" ]; }; </ins> }

The is from over 3 months ago. Some background info: Previously it was updated automatically by bot that runs . But the last builds have failed, e.g.:


Question: flycheck-rtags = fix-rtags super.flycheck-rtags; pdf-tools = super.pdf-tools.overrideAttrs (old: { <ins> # Temporary work around for: #   - https://github.com/vedang/pdf-tools/issues/102 #   - https://github.com/vedang/pdf-tools/issues/103 #   - https://github.com/vedang/pdf-tools/issues/109 CXXFLAGS = "-std=c++17"; </ins> nativeBuildInputs = [ pkgs.autoconf pkgs.automake

The emacs package fails to build against the poppler version introduced in . See upstream issue vedang/pdf-tools. Steps to reproduce the behavior: should build Build log: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I'm seeing the same thing.
Same for me
Here's a work around:
Since above PR is merged and pdf-tools builds on current HEAD, I will close this.


Question: { stdenv, lib, config, fetchFromGitHub, cmake, pkg-config , alsaSupport ? stdenv.isLinux, alsa-lib , pulseSupport ? config.pulseaudio or stdenv.isLinux, libpulseaudio <del> , jackSupport ? false, libjack2 </del> <ins> , jackSupport ? false, libjack2, soxr , pcapSupport ? false, libpcap </ins> }: stdenv.mkDerivation rec {

Scream does not compile with jack support when it is explicitly enabled through an overlay. nixpkgs.overlays = [ (final: prev: { scream = { jackSupport = true; }; }) ]
Error message?
There is no error, it just skips compiling it. someone else ran it and i think they said that it skips compiling it with jack support because soxr is missing -- Checking for module 'jack' -- Found jack, version 1.9.19 -- Checking for module 'soxr' -- No package 'soxr' found
See . In the meantime, you can try: nixpkgs.overlays = [ (final: prev: { scream = ( { jackSupport = true; }).overrideAttrs (old: { buildInputs = old.buildInputs ++ [ ]; }); }) ]


Question: --interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"  --set-rpath $rpath $out/share/spotify/spotify <del> librarypath="${lib.makeLibraryPath deps}:$libdir" wrapProgramShell $out/share/spotify/spotify  ''${gappsWrapperArgs[@]}  ${lib.optionalString (deviceScaleFactor != null) '' --add-flags "--force-device-scale-factor=${toString deviceScaleFactor}"  ''}  --prefix LD_LIBRARY_PATH : "$librarypath"  --prefix PATH : "${gnome.zenity}/bin"  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--enable-features=UseOzonePlatform --ozone-platform=wayland}}" </del> # fix Icon line in the desktop file (#48062) sed -i "s:^Icon=.*:Icon=spotify-client:" "$out/share/spotify/spotify.desktop"

When adding a local directory to spotify client, it always fails due to missing gsettings schema(s) and spotify crashes. This issue is the same as the one from 2021 Works as expected on arch based distros indicating that this an issue with nixpkgs Steps to reproduce the behavior: spotify Settings on Show Local Files ADD A SOURCE button Open a file chooser to select which directory to be . <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I can't actually reproduce the issue, but I do see some inherent packaging issues that I attempted to address. Can you test the linked PR?
I also cannot reproduce the issue. However, I have never actually had local files appear after I have their directories (without crashing).
Yes your PR solves the issue!!! Thanks a lot for the fast reply :) I would really like to learn more about packaging programs for nixpkgs so I can contribute more myself. Do you have any recommendations on how to learn the different options for mkDerivation, the different phases, wrapping programs and libraries, etc.? I feel like the documentation is basically non-existend. If anything comes to mind (including workshops, etc.) feel free to just send me an email (this issue is probably the wrong place to discuss this)