jiebi/CodeConvo huggingface dataset:
Change:
postPatch = '' substituteInPlace Makefile --replace "--static" "" <del> '' + lib.optionalString stdenv.isi686 '' substituteInPlace Makefile --replace "-flto" "" </del> ''; installPhase = ''

Discussion:
efibootmgr fails to compile from i686 to armv6l (raspberryPi), because is false and is passed in CFLAGS, however the gcc cross-compiler doesn't support the flag. Steps to reproduce the behavior: x86-64 Linux, The build to complete successfully. Changing the efibootmgr derivation to use instead of fixes the build but I'm not sure this is the right fix. It seems that the derivation is perhaps right, and gcc should support LTO on i686 for non-i686 target platforms. Perhaps the references in the gcc sections of pkgs/top-level/all- should read ? <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --efibootmgr doesn't have any maintainers listed and I think the actual problem relates to gcc. Please run and paste the result. Maintainer information:
It looks like LTO availability depends on this setting: So immediately I have a few thoughts: We should consolidate these definitions and make them available via e.g. gcc.passthru so that packages can check whether they are allowed to use LTO in a non ad-hoc way Your buildPlatform modification appears to be correct, as the enableLTO setting depends on gcc's hostPlatform rather than its targetPlatform
I agree that that's the effect, but is that the intent? Is LTO a problem on i686 hosts or i686 targets, or both? It looks like this was first introduced in by who might have some additional context for the change.
Good point, usually settings like that affect the target platform. It's possible this was only tested for the native case, so it's a good idea to verify the platform predicate is correct.
It was reaction to non-cross problems during bootstrapping. It's well possible that they won't appear when not bootstrapping (e.g. any cross). Confirming that gcc builds should be enough for the problems from my commit.
I see. It sounds like maybe switching on is more appropriate, then. I'm a bit new to Nix, is there a way to force a build from scratch rather than a fetch from cache? The docs are failing me here.

I think you want
Linking likely related so I don't forget to look into it along with this
Sorry, maybe I merged it too soon :sweat_smile: ?
No no worries, I didn't link it there because I don't think the supportsLTO ~ isi686 cleanup is your responsibility. There are probably other locations as well I'll need to look into.
Hmm, so I was thinking I'd figure out the right host/target platform distinction for gcc and then expose whether it has LTO with e.g. . But I'm unable to encounter any scenario where LTO doesn't work on i686, so I think we can reenable it fully, and I'll just remove the treewide i686-specific LTO workarounds if that sounds reasonable.
efivar LTO seems broken for an unrelated reason (it's broken on x86_64 too), everything else seems to work fine with LTO on i686 (regardless of native or cross compilation). PR coming soon.
Change:
</listitem> </varlistentry> <varlistentry> <del> <term>If it’s a <emphasis>desktop environment</emphasis> (including <emphasis>window managers</emphasis>):</term> </del> <ins> <term>If it’s a <emphasis>desktop environment</emphasis>:</term> </ins> <listitem> <para><filename>desktops</filename> (e.g. <filename>kde</filename>, <filename>gnome</filename>, <filename>enlightenment</filename>)</para> </listitem> </varlistentry> <varlistentry> <ins> <term>If it’s a <emphasis>window manager</emphasis>:</term> <listitem> <para><filename>applications/window-managers</filename> (e.g. <filename>awesome</filename>, <filename>compiz</filename>, <filename>stumpwm</filename>)</para> </listitem> </varlistentry> <varlistentry> </ins> <term>If it’s an <emphasis>application</emphasis>:</term> <listitem> <para>A (typically large) program with a distinct user

Discussion:
In the nixpkgs manual, : but 37 window-managers are in . Should I change the documentation to reflect this?
I don't know if that hierarchy makes sense at all, but yes we can change it.
I that hierarchy does not make sense, I think we should just remove it.
Change:
homepage = "https://github.com/fzwoch/obs-gstreamer"; maintainers = with maintainers; [ ahuzik pedrohlc ]; license = licenses.gpl2Plus; <del> platforms = [ "x86_64-linux" "i686-linux" ]; </del> <ins> platforms = platforms.linux; </ins> }; }

Discussion:
Project description GStreamer OBS Studio plugin Package already exists on Nixpkgs but without aarch64-linux support. AUR supports aarch64, so the project supports it Metadata homepage URL: source URL: license: gpl2Plus platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
]; propagatedBuildInputs = with python3Packages; [ <ins> pycurl </ins> pyyaml requests pygobject3

Discussion:
When using at first startup it tries to download some runtime, but seems to fail. Steps to reproduce the behavior: it next, next, install 's stuck at "Downloading" forever It actually downloads the required runtime. ! When running through the console I can see some additional info, and it shows: This repeats forever. Nothing, I think? <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
can you write what version of package you are using? It seems this problem from old version that still in stable and resolved in one that in unstable channel it seems you're maintaining bottles better than me now, can you add yourself into maintainers with new PR and backport it?
It's not solved by updating to 2022.11.14. Seems to be an upstream issue:
I'm indeed using the current version of the stable channel: I also tried the version from the unstable branch, but indeed that does not fix it as SuperSamus said. I'll keep an eye on the upstream issue.
I was able to fix this by and extracting it into To be clear, inside the folder there should be a folder, inside which are , , , etc.
Change:
sha256 = "0n09jd7yqj18mx6zqbg7kab4idg5llr15g6avafj74fpg1h7iimj"; }; <ins> postPatch = '' # fix build with gettext 0.20 sed -i 's/AM_GNU_GETTEXT/AM_GNU_GETTEXT([external])/' configure.in ''; </ins> nativeBuildInputs = [ autoreconfHook libtool pkgconfig ]; buildInputs       = [ file gtk2 libGLU gtkglarea ];

Discussion:
Describe the bug The (File System Visualizer) package is currently broken. It fails to build, with the error output referencing automake macros that are unsupported or undefined. To Reproduce Steps to reproduce the behavior: that the build fails. Expected behavior I expected the package to be built successfully and installed in my user environment. Screenshots If applicable, add screenshots to help explain your problem. Additional context Here is the build output I saw. Metadata Please run and paste the result. Maintainer information:
cc
Thank you for the report! It seems like a breaking change in gettext. I will push a fix ~tomorrow~ done.
Change:
./services/mail/roundcube.nix ./services/mail/sympa.nix ./services/mail/nullmailer.nix <ins> ./services/misc/ananicy.nix </ins> ./services/misc/airsonic.nix ./services/misc/ankisyncd.nix ./services/misc/apache-kafka.nix

Discussion:
Project description Ananicy (ANother Auto NICe daemon) — is a shell daemon created to manage processes' IO and CPU priorities, with community-driven set of rules for popular applications (anyone may add their own rule via github's pull request mechanism). It's mainly for desktop usage. Metadata homepage URL: source URL: license: gpl3 platforms: linux
Change:
let pname = "decent-sampler"; <del> version = "1.9.4"; </del> <ins> version = "1.10.0"; icon = fetchurl { url = "https://archive.org/download/ds-256/DS256.png"; hash = "sha256-SV8zY5QJ6uRSrLuGTmT1zwGoIIXCV9GD2ZNiqK+i1Bc="; }; </ins> decent-sampler = stdenv.mkDerivation { inherit pname version; src = fetchzip { <del> # dropbox link: https://www.dropbox.com/sh/dwyry6xpy5uut07/AABBJ84bjTTSQWzXGG5TOQpfa </del> <ins> # dropbox links: https://www.dropbox.com/sh/dwyry6xpy5uut07/AABBJ84bjTTSQWzXGG5TOQpfa </ins> url = "https://archive.org/download/decent-sampler-linux-static-download-mirror/Decent_Sampler-${version}-Linux-Static-x86_64.tar.gz"; <del> hash = "sha256-lTp/mukCwLNyeTcBT68eqa7aD0o11Bylbd93A5VCILU="; </del> <ins> hash = "sha256-KYCf/F2/ziuXDHim4FPZQBARiSywvQDJBzKbHua+3SM="; </ins> }; <ins> nativeBuildInputs = [ copyDesktopItems ]; desktopItems = [ (makeDesktopItem { type = "Application"; name = "decent-sampler"; desktopName = "Decent Sampler"; comment = "DecentSampler player"; icon = "decent-sampler"; exec = "decent-sampler"; categories = [ "Audio" "AudioVideo" ]; }) ]; </ins> installPhase = '' runHook preInstall install -Dm755 DecentSampler $out/bin/decent-sampler <ins> install -Dm755 DecentSampler.so -t $out/lib/vst install -d "$out/lib/vst3" && cp -r "DecentSampler.vst3" $out/lib/vst3 install -Dm444 ${icon} $out/share/pixmaps/decent-sampler.png </ins> runHook postInstall '';

Discussion:
Decent Sampler is supposed to have a standalone app, a VST2 plugin and a VST3 plugin. The package decent-sampler installs only the standalone app. The downloaded archive contains also which is the VST2 plugin and the directory which is the VST3 plugin. Steps to reproduce the behavior: decent-sampler. for the VST plugins 't find them. The VST3 plugin should be installed in of the package and the VST2 plugin too should be in the package, but I don't know where exactly. <!-- 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. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
++ optional (uilib == "gtk3") gtk3 ; <ins> # Since at least 2018 AD, GCC and other compilers run in `-fno-common` mode as # default, in order to comply with C standards and also get rid of some bad # quality code. Because of this, many codebases that weren't updated need to # be patched -- or the `-fcommon` flag should be explicitly passed to the # compiler # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678 # https://github.com/NixOS/nixpkgs/issues/54506 env.NIX_CFLAGS_COMPILE = "-fcommon"; </ins> preConfigure = '' cat <<EOF > Makefile.conf override NETSURF_GTK_RES_PATH  := $out/share/

Discussion:
Get netsurf onto your machine and attempt to execute it, notice how it is broken. Specifically nothing happens, other than the terminal (ST in this case) displays a single . Trying another terminal such as Kitty or the Linux console spews a sequence of characters onto the display. Neither behavior is correct. system: host os: multi-user?: sandbox: version: channels(root): channels(sna): nixpkgs:
That's because by default it uses the framebuffer. Try edit: oh wait you tried it on the linux console, which should support the fb. forget what I said then
I do have sixel support patched into ST so it should work using the framebuffer build. I tested in ST and the Linux console and it ended up working with some problems already mentioned in the PR.
Does it still support the framebuffer? It seems to set the GTK3 as the default. When I try to build , I get the following error:
^
Framebuffer still works. What happened is . should fix your error.
This unfortunately still gave me the same error, but perhaps I didn't set the environment variable right. nix repl: NIXCFLAGSCOMPILE = "-fcommon" :l <nixpkgs:b netsurf.browser.override { uilib="framebuffer"; } The error mentions certain fonts specifically, not sure what is up with that. Thanks for the pointer though!
does that work for you? If so, we could apply the fix in nixpkgs
Change:
postFixup = '' wrapProgram $out/bin/qutebrowser  "''${gappsWrapperArgs[@]}"  <del> "''${qtWrapperArgs[@]}" </del> <ins> "''${qtWrapperArgs[@]}"  --add-flags '--backend ${backend}' </ins> ''; meta = with stdenv.lib; {

Discussion:
The current version of qutebrowser (1.13.0, nixpkgs svn-revision: .) packaged in unstable fails to start with webkit backend. Forcing the backend in the resulting error dialog does nothing. To Reproduce Steps to reproduce the behavior: in qutebrowser Screenshots ! Notify maintainers
The qtwebkit backend was disabled in . Apparently at the time there was talk about dropping the backend but eventually they decided to keep it for a while. In any case here's what the current README says about it Soo, we could revert the commit but it seems it's going to be anyway. This is the reason, it looks like a variable that points to the qutebrowser executable is not actually resolved:
Thanks for the info regarding the readme and webkit. I'm pretty new to nixpks. Let me now if this would be a viable solution: and I'll make the PR. Also, where should I branch off of and what should be the target branch for my PR. It is the best I could come up with, because webkit and webengine depend on to different versions of qt5 so, we cannot easily have qutebrowser depend on both.
You can just revert the commit I mentioned: that should take care of also enabling qtwebkit by default, which is probably what you want. To make a PR you should target the master branch, also take a look at the .
Hmm... I don't really know, what to make of this part: in the current version it reads: and reverting just the other changes gives me build-errors.
Uhm, try something like this:
Now I get the original import error on starting qutebrowser, when I have set to . Maybe was the right solution after all, because that at least worked.
Change:
] ++ lib.optionals (unwrapped.hasFeature "gr-qtgui" unwrapped.features) # 3.7 builds with qt4 <del> (if unwrapped.versionAttr.major == "3.8" then </del> <ins> (if lib.versionAtLeast unwrapped.versionAttr.major "3.8" then </ins> [ "--prefix" "QT_PLUGIN_PATH" ":" "${

Discussion:
Describe the bug Qt5 is not being wrapped in Gnuradio 3.9. I believe there is an error here: Reproduce Steps to reproduce the behavior: a random source connected to a Qt GUI Sink the flow graph Expected behavior A Qt5 window should open with analysis tools. Screenshots ! Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(erdnaxe): channels(root): nixpkgs: Maintainer information:
Tried to change with Now everything is working fine !
That's great! thanks for trying. Could you please make a PR?
Change:
{stdenv, fetchurl, fuse, bison, flex_2_5_35, openssl, python, ncurses, readline, autoconf, automake, libtool, pkgconfig, zlib, libaio, libxml2, acl, sqlite <del> , liburcu, attr </del> <ins> , liburcu, attr, makeWrapper, coreutils, gnused, gnugrep, which </ins> }: let s = # Generated upstream information

Discussion:
The glusterfs derivation does not install mount.glusterfs. So it is not possible to mount glusterfs filesystems. ls /nix/store/8p888wid9lm02zw0gaqzdzv41d8yc75r-glusterfs-3.8.1/sbin fusermount-glusterfs gfindmissingfiles glfsheal gluster glusterd glusterfind glusterfs glusterfsd Install glusterfs and try to mount a glusterfs. Even if you don't have a cluster ready, mount should return an error: mount -t glusterfs 172.16.0.167:/var/gluster/testvol tmp/mnt Look inside the sbin folder, there is no mount.glusterfs file. The makefile that install mount.glusterfs () concatenates and to find the right directory. For an unknown reason, the configure flags set mountutildir to but when executed by the Makefile it get evaluated to . So by removing the configureFlag the file get installed properly. But then this script is not able to find basic utilities like sed, cat, grep, etc because no PATH is set. We can use makeWrapper to set it. On the postInstall phase I add: wrapProgram { [ pkgs.coreutils pkgs.gnugrep]}" And I also add makeWrapper to buildInputs. It still print an error about not found (even so it is in the PATH) but at least I can mount my glusterfs volumes. Should I do a PR for this or will someone else provide a better fix? System: 16.09.1272. (Flounder) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: "16.09.1272."
Possible (just run ), but point taken. Hm, I guess long long ago it tried to install to global and failed. Then I didn't notice the Makefile improvement during the updates… Not sure a better fix is possible here. Yes, a PR would be welcome.
Change:
uefiCdrom = makeBootTest "uefi-cdrom" '' cdrom => glob("${iso}/iso/*.iso"), <del> bios => '${pkgs.OVMF}/FV/OVMF.fd' </del> <ins> bios => '${pkgs.OVMF.fd}/FV/OVMF.fd' </ins> ''; uefiUsb = makeBootTest "uefi-usb" '' usb => glob("${iso}/iso/*.iso"), <del> bios => '${pkgs.OVMF}/FV/OVMF.fd' </del> <ins> bios => '${pkgs.OVMF.fd}/FV/OVMF.fd' </ins> ''; netboot = let

Discussion:
In , I introduced support in libvirtd for UEFI VM creation. rightfully remarked that this brings closure-size up too much. Looking into OVMF shows that only 1MB out of the 114MB install size is needed to enable said UEFI VM creation. I think that we should look into splitting out OVMF_(CODE|VARS) from the rest package.
Change:
inherit (darwin.apple_sdk.frameworks) Carbon; }; <ins> cyan = callPackage ../applications/graphics/cyan {}; </ins> cyanrip = callPackage ../applications/audio/cyanrip { }; centerim = callPackage ../applications/networking/instant-messengers/centerim { };

Discussion:
Project description Cyan is an open source cross-platform image viewer and converter, designed for prepress (print) work. Like converting an image from RGB to CMYK, or the other way around. Cyan supports color profiles complying with the International Color Consortium (ICC) standard, and strives to create as color-accurate images as possible, with support for RGB, CMYK and GRAY with up to 32-bit image depth. Metadata homepage URL: source license: gpl2+ platforms: unix, linux, darwin, ...
Change:
, buildPythonPackage , fetchFromGitHub , fetchpatch <ins> , setuptools </ins> , mypy , pytestCheckHook , python-lsp-server , pythonOlder <del> , toml </del> <ins> , tomli </ins> }: buildPythonPackage rec { pname = "pylsp-mypy"; <del> version = "0.6.6"; format = "setuptools"; </del> <ins> version = "0.6.7"; format = "pyproject"; </ins> disabled = pythonOlder "3.7"; src = fetchFromGitHub { <del> owner = "Richardk2n"; </del> <ins> owner = "python-lsp"; </ins> repo = "pylsp-mypy"; rev = "refs/tags/${version}"; <del> hash = "sha256-9B+GSEoQEqd1W/g0oup4xULKWOF0TgSG5DfBtyWA3vs="; </del> <ins> hash = "sha256-ZsNIw0xjxnU9Ue0C7TlhzVOCOCKEbCa2CsiiqeMb14I="; </ins> }; <ins> patches = [ # https://github.com/python-lsp/pylsp-mypy/pull/64 (fetchpatch { name = "fix-hanging-test.patch"; url = "https://github.com/python-lsp/pylsp-mypy/commit/90d28edb474135007804f1e041f88713a95736f9.patch"; hash = "sha256-3DVyUXVImRemXCuyoXlYbPJm6p8OnhBdEKmwjx88ets="; }) ]; nativeBuildInputs = [ setuptools ]; </ins> propagatedBuildInputs = [ mypy python-lsp-server <del> toml </del> <ins> ] ++ lib.optionals (pythonOlder "3.11") [ tomli </ins> ]; nativeCheckInputs = [

Discussion:
Builds ok on x86_64, but on aarch64-darwin it hangs every time at  Steps to reproduce the behavior: <details</detailsI'm surprised not to see other issues about this as it seems to be logic contained in a major package (pytest), so I wonder if it's a problem local to my system. I tried rerunning after and and outcome was the same. Please run and paste the result.
I can reproduce this and, in my case, it is caused by the test in pylsp-mypy. I do not yet know why.
I believe this will be fixed by I'm planning to wait a few days for a response from upstream before patching this in case the code has to change, but please feel free to pull it in earlier if you have a need.
Yes, that sounds suspicious -- I'll try to build the PR and report back.
Sure enough, that patch does the trick.
Change:
"-DBoost_INCLUDE_DIR=${lib.getDev boost}/include" "-DEIGEN3_INCLUDE_DIR=${lib.getDev eigen}/include/eigen3" "-DBUILD_TESTING=on" <ins> "-DPYTHON_EXECUTABLE:FILEPATH=${python.pythonForBuild.interpreter}" </ins> ] ++ lib.optionals (python.isPy3k && !stdenv.cc.isClang) [ "-DPYBIND11_CXX_STANDARD=-std=c++17" ];

Discussion:
Steps to reproduce the behavior: current "master" () When removing the check in boost (which seems invalid, it does build fine): actual reason is: It tries to use the aarch64 python3.9 executable on the host system (x84_64).
Change:
libX11 freefont_ttf nettle libconfig cmake ]; <ins> patches = [ # Fix obsolete spice header usage. Remove with the next release. See https://github.com/gnif/LookingGlass/pull/126 (fetchpatch { url = "https://github.com/gnif/LookingGlass/commit/2567447b24b28458ba0f09c766a643ad8d753255.patch"; sha256 = "04j2h75rpxd71szry15f31r6s0kgk96i8q9khdv9q3i2fvkf242n"; stripLen = 1; }) ]; </ins> enableParallelBuilding = true; sourceRoot = "source/client";

Discussion:
Add looking-glass-client package and rebuild. This used to work but something changed awhile back. I just commented out the package and forgot about it because I wasn't using it at the time. Now I'd like to use it again. system: host os: multi-user?: sandbox: version: channels(root): channels(nix): nixpkgs:
Change:
layan-kde = callPackage ../data/themes/layan-kde { }; <ins> lao = callPackage ../data/fonts/lao {}; </ins> lato = callPackage ../data/fonts/lato {}; league-of-moveable-type = callPackage ../data/fonts/league-of-moveable-type {};

Discussion:
Project description The package contains TrueType fonts for Lao language. Metadata homepage URL: source URL: license: gpl2+ platforms: all
Change:
, click , pytestCheckHook , shellingham <del> , pytest-cov </del> , pytest-xdist , pytest-sugar , coverage , mypy , black , isort <ins> , pythonOlder </ins> }: buildPythonPackage rec { pname = "typer"; <del> version = "0.3.2"; </del> <ins> version = "0.4.0"; disabled = pythonOlder "3.6"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "00v3h63dq8yxahp9vg3yb9r27l2niwv8gv0dbds9dzrc298dfmal"; </del> <ins> sha256 = "1pgm0zsylbmz1r96q4n3rfi0h3pn4jss2yfs83z0yxa90nmsxhv3"; </ins> }; <del> propagatedBuildInputs = [ click ]; </del> <ins> propagatedBuildInputs = [ click ]; </ins> checkInputs = [ pytestCheckHook <del> pytest-cov </del> pytest-xdist pytest-sugar shellingham

Discussion:
Describe the bug typer is incompatible with click 8: Steps to reproduce Notify maintainers Metadata Maintainer information:
I have a version of typer in my NUR that uses some WIP changes to support click v8 (see ) and disables the tests to sidestep remaining issues: With that I was able to get a build that I could use with nixos master for some downstream dependencies I needed (authcaptureproxy for homeassistant). HTH
I just released Typer , which is compatible with both Click 7 and Click 8. :tada: