jiebi/CodeConvo huggingface dataset:
Change:
license = licenses.gpl2; maintainers = [ maintainers.rickynils ]; platforms = platforms.linux; <ins> broken = true; # does not work with our new syslog-ng version yet </ins> }; }

Discussion:
I'm upgrading my systems from NixOS 16.03 to 16.09 and I'm trying to get syslog-ng working again. It's currently configured as: The issue is that systemd is not noticing that syslog-ng has started: I do see that syslog-ng is running: Note that the systemd syslog-ng service is with This that syslog-ng should notify systemd when it has started up. My current hypotheses is that with the systemd upgrade to 231 something in the notification protocol has changed causing the syslog-ng notification to fail.
It has strange config: how could this work ? could you test this? syslog-ng at least starts for me
thanks with those changes syslog-ng starts up correctly.
means that the syslog-ng unit will be activated (started) if gets activated. By itself this relation defines no order. That's why you can add and relations as you wish. As I've mention in , the root problem is that our current version of syslog-ng can't be built with our current version of systemd and thus the sd-notify feature is not present.
Hi I did some work on the syslog-ng upgrade. I've managed to get syslog-ng-3.9.1 to build with I will now test this a bit.
Change:
stdenv = stdenv.override (drv: { allowedRequisites = null; cc = self.clang; <del> # Use the gcc libstdc++ when targeting linux. extraBuildInputs = if stdenv.cc.isGNU then [ libstdcxxHook ] else drv.extraBuildInputs; </del> <ins> # Don't include the libc++ and libc++abi from the original stdenv. extraBuildInputs = stdenv.lib.optional stdenv.isDarwin darwin.CF; </ins> }); <del> libcxxStdenv = overrideCC stdenv self.libcxxClang; </del> <ins> libcxxStdenv = stdenv.override (drv: { allowedRequisites = null; cc = self.libcxxClang; # Don't include the libc++ and libc++abi from the original stdenv. extraBuildInputs = stdenv.lib.optional stdenv.isDarwin darwin.CF; }); </ins> lld = callPackage ./lld.nix {};

Discussion:
In Nixpkgs 17.09, 3.9 cannot find libstdc++ headers: This does work correctly with Clang 4.0 in 17.09, or Clang 3.9 in 17.03. Setting shows that the cc-wrapper is not adding the appropriate flags pointing to libstdc++ in gcc. See above. System: NixOS 17.03 Nix version: 1.12pre Nixpkgs version: 17.09beta285. Sandboxing enabled: no
According to git-bisect, one of the following commits is causing the issue (all by
Hmm, was supposed to have fixed this, but I guess only fixed 4.0. any idea?
Really thought I already applied those changes to the other versions, must have forgotten to push or something.
Ah I see now---I should have noticed when reviewing that. While we're at it, maybe we should inject it in cc-wrapper instead of stdenv? This mirrors and keeps slimmer.
Change:
github-commenter = callPackage ../development/tools/github-commenter { }; <del> github-desktop = callPackage ../applications/version-management/github-desktop { }; </del> <ins> github-desktop = callPackage ../applications/version-management/github-desktop { curl = curl.override { openssl = openssl_1_1; }; }; </ins> github-to-sqlite = with python3Packages; toPythonApplication github-to-sqlite;

Discussion:
Steps to reproduce the behavior: githhub-desktop Libs not to the Update of Package:
This issue is addressed by
Change:
}; buildInputs = [ cmake ]; <ins> nativeBuildInputs = [ removeReferencesTo ]; # It used to reference it, in the past, but thanks to the postFixup hook, now # it doesn't. disallowedReferences = [ stdenv.cc.cc ]; postFixup = stdenv.lib.optionalString stdenv.isLinux '' remove-references-to -t ${stdenv.cc.cc} "$(readlink -f $out/lib/libgme.so)" ''; </ins> }

Discussion:
Describe the bug references . I can't figure out yet why. To Reproduce Expected behavior No gcc reference. Additional context is a dependency of which is a common dependency for many applications. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(doron): nixpkgs: Maintainer information:
GitHub doesn't automatically close issues with PRs that had ?
It does usually, not sure what went wrong here.
Change:
cherrypy flask flask-restful flask-restplus flask-compress flask_login flask-cors <del> pyparsing zxcvbn-python future </del> <ins> pyparsing zxcvbn future </ins> progressbar # Optional requirements deluge-client

Discussion:
Tried to update my server but it refuses to build because of flexget. Nixos Unstable flexget as service Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(hyper): channels(root): nixpkgs:
flexget works for you?
r-ryantm is my bot. Anyway, it looks like it successfully built it in It looks like it was merged on May 1st, and continued to build on Hydra after May 1st: Probably some dependency change messed it up. You could do some kind of binary bisection to figure out what commit broke it, or try to track down the error message, maybe zxcvbn-python is what broke it? cc because it's python related.
I don't know what a binary disection is.
No, this is simply flexget again that pins dependencies while it shouldn't. this has happened many times before so surely you know how to solve it by now.
I don't know what binary disection is.
this happened because , and landed in nixpkgs in the . I'm going to make a PR for this
Change:
lilo = callPackage ../tools/misc/lilo { }; <del> logseq = callPackage ../applications/misc/logseq { electron = electron_20; }; </del> <ins> logseq = callPackage ../applications/misc/logseq { }; </ins> natls = callPackage ../tools/misc/natls { };

Discussion:
When exporting the graph, logseq throws a permission exception. Steps to reproduce the behavior: a new graph a few pages them public ()) the graph The graph should successfully export and opening it should show a read-only view of the graph. The logseq documentation itself is an example thereof. If applicable, add screenshots to help explain your problem. Bug was first reported in the original repo When running the AppImage with it's fine because it's extracted into , but when the app is in then it won't work because of the read-only status. I tested the flatpak version because I suspected the same problem would occur, but the directories are mounted read-write in a read-only volume. So, 2 options exist as I see it: fix it upstream, but I don't know Clojure nor Electron start the AppImage with instead of extracting it Please run and paste the result.
Change:
<del> { stdenv, fetchFromGitHub, fetchurl, pkgconfig, intltool, itstool, python3, wrapGAppsHook , python3Packages, gst_all_1, gtk3 , gobject-introspection, librsvg, gnome3, libnotify, gsound , meson, ninja, gsettings-desktop-schemas </del> <ins> { stdenv , fetchFromGitHub , fetchurl , fetchpatch , pkg-config , gettext , itstool , python3 , wrapGAppsHook , python3Packages , gst_all_1 , gtk3 , gobject-introspection , librsvg , gnome3 , libnotify , gsound , meson , ninja , gsettings-desktop-schemas </ins> }: let <del> version = "0.999"; # gst-transcoder will eventually be merged with gstreamer (according to # gst-transcoder 1.8.0 release notes). For now the only user is pitivi so we # don't bother exposing the package to all of nixpkgs. </del> <ins> # gst-transcoder was merged with gst-plugins-bad 1.18. # TODO: switch to that once available. </ins> gst-transcoder = stdenv.mkDerivation rec { version = "1.14.1"; pname = "gst-transcoder";

Discussion:
Describe the bug To Reproduce Steps to reproduce the behavior: Expected behavior builds and runs Notify maintainers It currently has no maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos Maintainer information:
Change:
description = "A simple automation tool"; license = with licenses; [ gpl3] ; maintainers = with maintainers; [ joamaki ]; <del> platforms = with platforms; [ linux darwin ]; </del> <ins> platforms = with platforms; linux ++ darwin; </ins> }; };

Discussion:
ahh, should be
Packages , and in need this fix
I do find it odd that this wasn't enforced on me when building with the 'wrong' platforms.
is not checked when doing
Change:
, ... } @ args: let <del> version = "5.15.137-rt71"; # updated by ./update-rt.sh </del> <ins> version = "5.15.141-rt72"; # updated by ./update-rt.sh </ins> branch = lib.versions.majorMinor version; kversion = builtins.elemAt (lib.splitString "-" version) 0; in buildLinux (args // {

Discussion:
Apparently upstream stable kernels 6.1.65 (NixOS 23.11 default) and .64 have a cherry-picking bug that can create data corruption on ext4 Probably NixOS should update to 6.1.66 (released 2 days ago) as soon as possible
Looks like this was already dealth with: Currently building on Hydra:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I believe the realtime kernel from the branch still contains this bug? Made an issue:
Change:
config = mkIf cfg.enable { environment.systemPackages = [ pkgs.auto-cpufreq ]; <del> systemd.packages = [ pkgs.auto-cpufreq ]; systemd.services.auto-cpufreq.path = with pkgs; [ bash coreutils ]; </del> <ins> systemd = { packages = [ pkgs.auto-cpufreq ]; services.auto-cpufreq = { # Workaround for https://github.com/NixOS/nixpkgs/issues/81138 wantedBy = [ "multi-user.target" ]; path = with pkgs; [ bash coreutils ]; }; }; </ins> }; }

Discussion:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it
Change:
inherit version; src = fetchurl { <del> url = "http://a1227.g.akamai.net/f/1227/40484/7d/download.ebz.epson.net/dsc/f/01/00/01/58/65/cd71929d2bf41ebf7e96f68fa9f1279556545ef1/Epson-ALC1100-filter-1.2.tar.gz"; sha256 = "0q0bf4dfm4v69l7xg6sgkh7rwb0h77i8j9kplq1dfkd208g7y81p"; </del> <ins> url = "https://download3.ebz.epson.net/dsc/f/03/00/11/33/07/4027e99517b5c388d444b8444d719b4b77f7e9db/Epson-ALC1100-filter-1.2.tar.gz"; sha256 = "1dfw75a3kj2aa4iicvlk9kz3jarrsikpnpd4cdpw79scfc5mwm2p"; </ins> }; patches = [ ./cups-data-dir.patch ./ppd.patch ];

Discussion:
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 . on the on .
Change:
${backend}.wait_for_unit("${backend}-nginx.service") ${backend}.wait_for_open_port(8181) ${backend}.wait_until_succeeds("curl -f http://localhost:8181 | grep Hello") <ins> ${backend}.succeed("systemctl stop ${backend}-nginx.service", timeout=10) </ins> ''; };

Discussion:
I ran into an issue when playing with oci-containers. Stopping the containers results in a coredump for some containers, because the monitor process is killed with the rest of the cgroup. Playing with the stop script and looking at the systemd unit generated with the problem seems to be the check for : This will only run if the result is not "success". But "success" is the normal value when succeeded. Maybe this should use ? Then if the container exited with an error by itself the would not run. No such check is present in the podman generated unit: The same is used for docker, so probably the same error there.
Change:
<del> { lib, buildGoModule, fetchFromGitHub </del> <ins> { lib, buildGoModule, fetchFromGitHub, fetchpatch </ins> , nixosTests, postgresql, postgresqlTestHook }: buildGoModule rec {

Discussion:
A clear and concise description of what the bug is. Matrix server dendrite does not start after upgrade to 0.13.1 This is fixed in - Prepare statement on an existing transaction Steps to reproduce the behavior: dendrite < 0.13.1 running as a service with sqlite as database backend which upgrades dendrite to 0.13.1 as per Matrix server dendrite not crashing fixed in Please run and paste the result.
Sorry for that, it seems like the issue slipped through the test suite, because it starts up an empty dendrite instance. I'll make a PR to apply the commit provided above.
I've proposed PR to address this issue. Let me know if the issue still occurs after applying the commit.
Works :partying_face: thanks a lot for the quick fix !! :hugs:
Change:
xorg.libXScrnSaver ]; <ins> # convert name of wrapped binary, e.g. .lxqt-whatever-wrapped to the original name, e.g. lxqt-whatever so binaries can find their resources patches = [ ./fix-application-path.patch ]; </ins> postPatch = '' sed -i "s|''${POLKITQT-1_POLICY_FILES_INSTALL_DIR}|''${out}/share/polkit-1/actions|" CMakeLists.txt '';

Discussion:
LXQt has invalid default default settings, giving it a black-on-black theme, e.g. the clock in the panel is not readable (black font on black bg) and the background image is missing. (default points to /nix/store/w2xzdhvlq9bz4kd6s298gjy6dlssdq37-lxqt-build-tools-0.6.0/share/lxqt/themes/frost/lxqt-origami- while it should be sth matching /nix/store/*-lxqt-themes-0.14.0/share/lxqt/themes/frost/lxqt-origami-) Further, Themes are not listed and changing the panel theme has no effect. The issue reminds of though I am not knowledgeable enough to confirm this. is listed in Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs:
Known issue see (just forgot to report it :sweat_smile:)
Ah, I only searched for open PRs.. Let's also Cross-Ref here.
Fixed the wallpaper, panel/theme issue still applies (LXQt 0.15.0)
Have you discovered a way to fix this? The issue also applies using lightdm.
I would like to ask maintainers of the Qt libraries in nixpkgs to take a look at this issue, if possible. Maybe they can help in fixing this issue, which exists since LXQt was changed to use qt5's (). cc
Change:
ln -s $out/bin/FreeCADCmd $out/bin/freecadcmd ''; <del> meta = with lib; { </del> <ins> meta = { </ins> homepage = "https://www.freecad.org"; description = "General purpose Open Source 3D CAD/MCAD/CAx/CAE/PLM modeler"; longDescription = ''

Discussion:
Package name: freecad Latest released version: 0.21.0 Current version on the unstable channel: 0.20.2 Current version on the stable/release channel: 0.20.2 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Out of curiosity, anyone working on this ?
PR opened at
Change:
]; strictDeps = true; <del> nativeBuildInputs = [ autoreconfHook perl groff texinfo pcre] </del> <ins> nativeBuildInputs = [ autoreconfHook perl groff texinfo pkg-config ] </ins> ++ lib.optionals stdenv.isLinux [ util-linux yodl ]; buildInputs = [ ncurses pcre ];

Discussion:
Steps to reproduce the behavior: nixpkgs/#pkgsCross.armv7l-hf- () Not sure what's going on here, looking at zsh looks like it should build for ARM without any special handling. <!-- 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.
Most likely something related to glibc, since building with musl (at least through pkgsStatic) works. Also since it can't find any of these during configure:

This is from nixos-unstable current. For some reason, I get build failures with ZSH. This is with a nixpkgs (system=x86_64-linux) and nixpkgs.crossSystem set to . This seems to be the same failure (I checked, its the same derivation): Steps to reproduce the behavior: ... ... ... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
couldn't fix it. I'll leave this assigned to myself so i remember to take a another shot at it in ~6 months
Fixed by
Change:
thunderbird = thunderbird-78; thunderbird-78 = callPackage ../applications/networking/mailreaders/thunderbird { <del> inherit (rustPackages) cargo rustc; </del> <ins> # Using older Rust for workaround: # https://bugzilla.mozilla.org/show_bug.cgi?id=1663715 inherit (rustPackages_1_45) cargo rustc; </ins> libpng = libpng_apng; icu = icu67; libvpx = libvpx_1_8;

Discussion:
Describe the bug
There is a version update available
Proposal to increase build timeout
That update PR includes a workaround (using older rust).
Keeping this open until the channel progresses.
updated to .
Could setting help?
we now have an actual failure on master cc
Related
fixes the build of thunderbird.
Channel advanced.
Change:
doCheck = false;  # circular dependency with pytest }); <ins> wcwidth = callPackage ../development/python2-modules/wcwidth { inherit wcwidth; }; </ins> wheel = callPackage ../development/python2-modules/wheel { }; zeek = disabled super.zeek;

Discussion:
Steps to reproduce the behavior: I am able to build using July 27's , but not with the more recent s.
I believe this is related to Henceforth, all python2 builds will be broken. I am trying to pin nixpkgs before this commit, and I will report back how it goes.
hey, do you mind giving a try?
I can confirm that pinning python2 to the parent of works for me. I am actually not using fahclient but another python2 package (), but the error message is identical so I didn't bother to open a new issue. Maybe can check?
Change:
X11Xft = callPackage ../development/libraries/haskell/X11-xft {}; <ins> xdgBasedir = callPackage ../development/libraries/haskell/xdg-basedir {}; </ins> xdot = callPackage ../development/libraries/haskell/xdot { polyparse = self.polyparse_1_7; };

Discussion:
I'm planning to use nix as a package manager for my development toolchain, but not do the actual development in nix, is that a supported use case? I've hit some issues and have been sending in PRs to resolve them, but looking into it more the issues I've been hitting might have been derivations just working as intended. explains that library derivations in Nix only work when used in a nix environment, be it nix-shell or within nixpkgs. Is the same true for all development derivations, for example compilers and build tools? Examples: ++ doesn't work outside of nix-shell on darwin, but it does on linux, and I'm not sure which of the two is correct (). creates compiler wrappers to handle the way flags from dependencies are propagated in nixpkgs, but those wrappers are unnecessary when using the compilers from profiles. the bazel derivation is a script that wraps bazel to make it use clang and java from nix, instead of resolving it from the caller's , so that it can be used from within nixpkgs, but it results in a bazel that doesn't function correctly when installed. If existing development derivations are meant to be only used in a nix environment, would it be ok to add new derivations for use outside of a nix environment?
Nixpkgs do not explicitly support C++ compilers outside Nix environment, but this is a valuable use case and it would be great if you could work towards it.
It won't be helpful if there's no convention around it, how would someone find out which specific compilers work outside a Nix environment and which don't?
Either the default compilers will work (, ), or people will discover the new compilers (e.g. ) in the list of packages, in Nixpkgs issues, on the wiki, on IRC etc.
I have managed to work around this issue by creating wrappers for the compilers tailored to the specific use cases I have. It works very well, and it seems it's what others are doing as well. I'll close this issue since it's not relevant anymore.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
poetry = self.callPackage ./unwrapped.nix { }; # version overrides required by poetry and its plugins <ins> cachecontrol = super.cachecontrol.overridePythonAttrs (old: rec { version = "0.12.14"; format = "setuptools"; src = fetchFromGitHub { owner = "ionrock"; repo = "cachecontrol"; rev = "v${version}"; hash = "sha256-BuBaKP7OAYoT+SPVhtE6l9U/KmN21OKTL6poV5a6+0c="; }; nativeCheckInputs = old.nativeCheckInputs ++ [ self.lockfile ]; }); </ins> platformdirs = super.platformdirs.overridePythonAttrs (old: rec { version = "2.6.2"; src = fetchFromGitHub {

Discussion:
Steps to reproduce the behavior: poetry (e.g. ) Tested on darwin and NixOS, both on ARM64. Using nixpkgs-unstable. or Please run and paste the result.
Broken by . See also
Change:
# is why we use the more obscure "bfd" and not "binutils" for this # choice. else                                     "bfd"; <del> extensions = rec { sharedLibrary = assert final.hasSharedLibraries; /**/ if final.isDarwin  then ".dylib" </del> <ins> extensions = lib.optionalAttrs final.hasSharedLibraries { sharedLibrary = if      final.isDarwin  then ".dylib" </ins> else if final.isWindows then ".dll" else                         ".so"; <ins> } // { </ins> staticLibrary = /**/ if final.isWindows then ".lib" else                         ".a"; library = <del> /**/ if final.isStatic then staticLibrary else                        sharedLibrary; </del> <ins> /**/ if final.isStatic then final.extensions.staticLibrary else                        final.extensions.sharedLibrary; </ins> executable = /**/ if final.isWindows then ".exe" else                         "";

Discussion:
Nix fails to build on nixpkgs master. Steps to reproduce the behavior: unstable channel -channel --update works: fails: failure: Both invocations should succeed as they are isomorphic, i.e. has an unused let binding that causes to fail. Looks like this PR may have introduced the assert that causes the problem , After some investigation a colleague pointed out that the issue may have to do with the instability of attrset comparison due to laziness in nix, comparison happens here and looks like invocation in somehow cause a different evaluation order of attrset attribute comparison: if isStatic is compared first we don't see the assert If extensions compares first we stumble on the assert and fail. who the assert that fails nix package maintainers Please run and paste the result.
With something like we can deterministically crash the eval:
Same issue in
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This was my fault. The fix is: Unfortunately we can't provide useful error messages when people use sub-attributes of , because it is expected that you can compare two attrsets using , which will force the . We should probably move anything fallible (like ) out of these attrsets, so we can provide useful error messages instead of just returning .