jiebi/CodeConvo huggingface dataset:
Change:
the attribute inside a user-level systemd service seems to be ignored. I have three observations to suggest this. With this snippet from (service details aren't important, just for concreteness) If I run , I see batterycheck.service, but no corresponding timer. If I run , I again see the .service file, but no timer file. If I remove the startAt line and run , I can see from the output that no new environment is being built. I'm pretty sure that this functionality used to work several months ago, when I created this unit definition.

Discussion:
}) (filterAttrs (name: service: service.startAt != "") cfg.services); <ins> # Generate timer units for all services that have a ‘startAt’ value. systemd.user.timers = mapAttrs (name: service: { wantedBy = [ "timers.target" ]; timerConfig.OnCalendar = service.startAt; }) (filterAttrs (name: service: service.startAt != "") cfg.user.services); </ins> systemd.sockets.systemd-journal-gatewayd.wantedBy = optional config.services.journald.enableHttpGateway "sockets.target";
Change:
Describe the bug I cannot make a shell with pandas installed. To Reproduce Expected behavior A shell opens and works. Additional context <details<summaryI get this error message:</summary</detailsNotify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(noah): nixpkgs: Maintainer information:

Discussion:
, tables , xlwt , runtimeShell <ins> , isPy38 </ins> , libcxx ? null }:

"['pandas/src/klib', 'pandas/src', '$cpp_sdk']" ''; <del> setupPyBuildFlags = [ </del> <ins> # Parallel Cythonization is broken in Python 3.8 on Darwin. Fixed in the next # release. https://github.com/pandas-dev/pandas/pull/30862 setupPyBuildFlags = optionals (!(isPy38 && isDarwin)) [ </ins> # As suggested by # https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#creating-a-python-environment "--parallel=$NIX_BUILD_CORES"
Change:
Describe the bug building the package fails. To Reproduce Steps to reproduce the behavior: and wait Expected behavior Successfully building swift to be used. Notify maintainers Maintainer: Last 4: … Metadata Error
Seems as is used for building rather than . Probably happened during experiments to declare . Apart from that I'm not a swift maintainer, so if the issue is more complex, I can't help I'm afraid.
I think the Python warning is actually benign. I see a build error related to a change in the handling of . Commit appears to break it for me. I can offer a , which you can try like this: But I am not sure what the proper fix is. I would like to ask for comment.
I have pushed a new fix to my . This uses the proper fix as suggested by It would be nice, if someone can confirm it works. I have also opened PR with this fix.

Discussion:
''; buildPhase = '' <del> # gcc-6.4.0/include/c++/6.4.0/cstdlib:75:15: fatal error: 'stdlib.h' file not found export NIX_CFLAGS_COMPILE="$(< $NIX_CC/nix-support/libcxx-cxxflags) $NIX_CFLAGS_COMPILE" </del> <ins> # explicitly include C++ headers to prevent errors where stdlib.h is not found from cstdlib export NIX_CFLAGS_COMPILE="$(< ${clang}/nix-support/libcxx-cxxflags) $NIX_CFLAGS_COMPILE" </ins> # During the Swift build, a full local LLVM build is performed and the resulting clang is invoked. # This compiler is not using the Nix wrappers, so it needs some help to find things. export NIX_LDFLAGS_BEFORE="-rpath ${clang.cc.gcc.lib}/lib -L${clang.cc.gcc.lib}/lib $NIX_LDFLAGS_BEFORE"
Change:
Describe the bug building the package fails. To Reproduce Steps to reproduce the behavior: and wait Expected behavior Successfully building jdk14. Notify maintainers Metadata Error
Please reopen. The build still fails for me.
2 fails differently for me, but it fails. So maybe let's open a new issue?

Discussion:
let major = "14"; <del> update = ".0.1"; </del> <ins> update = ".0.2"; </ins> build = "-ga"; openjdk = stdenv.mkDerivation rec {

src = fetchurl { url = "http://hg.openjdk.java.net/jdk-updates/jdk${major}u/archive/jdk-${version}.tar.gz"; <del> sha256 = "0ic7dcrzk62jc65yrshs6xlclmsha7z52bia5s2bkllw1zpmdmip"; </del> <ins> sha256 = "1s1pc6ihzf0awp4hbaqfxmbica0hnrg8nr7s0yd2hfn7nan8xmf3"; </ins> }; nativeBuildInputs = [ pkgconfig autoconf ];
Change:
Describe the bug building the package fails. To Reproduce Steps to reproduce the behavior: and wait Expected behavior Successfully building python37Packages.pwntools to be used. Notify maintainers Maintainer: Metadata Error
Will be fixed via
lol, I didn't see this issue, I started fixing it today because I recently noticed it was broken as well :D

Discussion:
<del> { stdenv, fetchurl, pkgconfig, python }: </del> <ins> { stdenv, fetchurl, pkgconfig, python, cmocka, hexdump, writeScriptBin, binutils-unwrapped }: </ins> stdenv.mkDerivation rec { pname = "unicorn-emulator"; <del> version = "1.0.1"; </del> <ins> version = "1.0.2-rc4"; </ins> src = fetchurl { url    = "https://github.com/unicorn-engine/unicorn/archive/${version}.tar.gz"; <del> sha256 = "0z01apwmvhvdldm372ww9pjfn45awkw3m90c0h4v0nj0ihmlysis"; </del> <ins> sha256 = "05w43jq3r97l3c8ggc745ai8m5l93p1b6q6cfp1zwzz6hl5kifiv"; </ins> }; <del> configurePhase = '' patchShebangs make.sh ''; buildPhase = '' ./make.sh '' + stdenv.lib.optionalString stdenv.isDarwin "macos-universal-no"; installPhase = '' env PREFIX=$out ./make.sh install ''; </del> <ins> PREFIX = placeholder "out"; MACOS_UNIVERSAL = stdenv.lib.optionalString stdenv.isDarwin "no"; NIX_CFLAGS_COMPILE = "-Wno-error"; doCheck = !stdenv.isDarwin; checkInputs = [ cmocka hexdump python.pkgs.setuptools ]; </ins> nativeBuildInputs = [ pkgconfig python ]; enableParallelBuilding = true;

<del> { stdenv, buildPythonPackage, fetchPypi, isPy3k , Mako, packaging, pysocks, pygments, ROPGadget , capstone, paramiko, pip, psutil , pyelftools, pyserial, dateutil , requests, tox, unicorn, intervaltree, fetchpatch }: </del> <ins> { stdenv , buildPythonPackage , fetchPypi , isPy3k , Mako , packaging , pysocks , pygments , ROPGadget , capstone , paramiko , pip , psutil , pyelftools , pyserial , dateutil , requests , tox , unicorn , intervaltree , fetchpatch }: </ins> buildPythonPackage rec { <del> version = "4.1.1"; </del> <ins> version = "4.2.1"; </ins> pname = "pwntools"; src = fetchPypi { inherit pname version; <del> sha256 = "694ce7a6cfca0ad40eae36c1d2663c44eb953f84785c63daa9752b4dfa7f39d8"; </del> <ins> sha256 = "1fh7sq9wrcfvn44qryln9cyg99pilvyq9bp80758lgdd6ss6hdqd"; </ins> }; <del> propagatedBuildInputs = [ Mako packaging pysocks pygments ROPGadget capstone paramiko pip psutil pyelftools pyserial dateutil requests tox unicorn intervaltree ]; </del> <ins> # Upstream has set an upper bound on unicorn because of https://github.com/Gallopsled/pwntools/issues/1538, # but since that is a niche use case and it requires extra work to get unicorn 1.0.2rc3 to work we relax # the bound here. Check if this is still necessary when updating! postPatch = '' sed -i 's/unicorn>=1.0.2rc1,<1.0.2rc4/unicorn>=1.0.2rc1/' setup.py ''; propagatedBuildInputs = [ Mako packaging pysocks pygments ROPGadget capstone paramiko pip psutil pyelftools pyserial dateutil requests tox unicorn intervaltree ]; </ins> doCheck = false; # no setuptools tests for the package
Change:
Describe the bug Currently on a local checkout of , is incapable of linking i686 code. If attempting to do so, finds only the x8664 variants of some of the crucial compiler dependencies. I think this is a relevant failure, started failing 2020-07-03. To Reproduce Steps to reproduce the behavior: to build a 32-bit binary in a derivation via (specifically this stdenv, not just ) Linker will be unable to find any of the gcc dependencies (, , , , …) Expected behavior The code compiles fine without any problems. () Screenshots (Code is a derivation I've been working on, shouldn't matter for this bug.) ! Additional context Fetching a shell with and running the same command works fine. Notify maintainers Don't know who or what broke it, only that it did break at some point. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(bt1cn): nixpkgs: (I know I should update my system) Maintainer information:
I've also encountered this problem, but I switched to and forgot about it.
It's unfortunately not that easy for my use case, I am trying to package something that specifically requires Clang capable of linking both 64-bit and 32-bit code. I rebased my derivation on a checkout of (last known-good commit for this test) and the build indeed progresses past the first 32-bit linking. I'll try to figure out the exact commit that broke this when I have abit more time at hand.
Oh sorry, I meant that I forgot to report an issue because I found a workaround. I didn't mean to suggest it as a solution. I would still prefer to use so I will spend some time looking into this too.
Been running a git bisect since yesterday, still need to do the final build but it seems like it's homing in on being the breaking commit.
Bisect indeed blames . CC because you committed it, can you take a closer look at this?
Yes this is my fault and I need to fix it.
Has there been any progress on fixing this? It would be great to have working again before the 20.09 release.
I found to be the first commit introducing the break.
I marked this as stale due to inactivity. &rarr;
Still broken, see
Are there any updates on the issue or what we could do to help speed up the development of a fix? For reference, I have tried to use from the current master branch: EDIT: Referencing in
The following patch fixes the issue but we are currently working on a refactoring of the multilib wrappers in .
can you please test the PR and confirm if it fixes the issue on your end? Thank you!

Discussion:
lib = gcc_multi_sysroot; }; } '' <del> mkdir -p $out/lib/gcc </del> <ins> mkdir -p $out/lib{,64}/gcc </ins> <del> ln -s ${combine gcc64}/lib/gcc/* $out/lib/gcc/ </del> <ins> ln -s ${combine gcc64}/lib/gcc/* $out/lib64/gcc/ </ins> ln -s ${combine gcc32}/lib/gcc/* $out/lib/gcc/ # XXX: This shouldn't be needed, clang just doesn't look for "i686-unknown" ln -s $out/lib/gcc/i686-unknown-linux-gnu $out/lib/gcc/i686-pc-linux-gnu
Change:
Package: hexen Error: Makefile:157: recipe for target 'mmisc.o' failed Platform: openSUSE 13.1, x8664, XFCE Version: nix-env (Nix) 1.9
It builds fine for 32bit x86 architectures. I’ve no idea if it runs however. I don’t know if this program has been ever meant to be built on x86_64.
Hmm, that's a good point. If it isn't meant to run on x86_64, would there be some way to indicate as such in the file, eg. using an ?
Setting the attribute to should be enough.
The i686 version builds for me but doesn't run.
(triage) status?
Still doesn't build on x64.
(triage) and now?
Still fails on on NixOS 18.03.
Then I suggest we remove it. Can you prepare a patch?

Discussion:
<del> {stdenv, fetchurl, SDL} : stdenv.mkDerivation { name = "hexen-0.2.3"; src = fetchurl { url = https://www.libsdl.org/projects/hexen/src/hexen-0.2.3.tar.gz; sha256 = "c1433e930f2003c5f817f935406bb28ba15298a15b1c11f83f42df3e9f1f3bc4"; }; buildInputs = [ SDL ]; meta = { homepage = http://www.libsdl.org/projects/hexen/; description = "Port of Raven Software's popular Hexen 3-D shooter game"; license = stdenv.lib.licenses.free; broken = true; }; } </del>

hamster-time-traker = throw "hamster-time-tracker has been removed from nixpkgs, as it was unmaintained."; # added 2019-12-10 heimdalFull = heimdal; # added 2018-05-01 hepmc = hepmc2; # added 2019-08-05 <ins> hexen = throw "hexen (SDL port) has been removed: Abandoned by upstream."; # added 2019-12-11 </ins> hicolor_icon_theme = hicolor-icon-theme; # added 2018-02-25 htmlTidy = html-tidy;  # added 2014-12-06 iana_etc = iana-etc;  # added 2017-03-08

inherit (haskellPackages) ghcWithPackages; }; <del> hexen = callPackage ../games/hexen { }; </del> holdingnuts = callPackage ../games/holdingnuts { }; hyperrogue = callPackage ../games/hyperrogue { };
Change:
Any executable built with the stdenv will print "Killed: 9" when run; the culprit is our copy of dyld, which I assume is now blacklisted by the security changes Apple has made. I'll investigate the changes and see if I can get a copy of dyld that works properly, but in the meantime, we can use . Fortunately it has no external dependencies so we don't have to poke more holes in the sandbox.
Could we close this?
Yeah, from what I've heard it isn't an issue anymore.

Discussion:
{stdenv, fetchurl}: stdenv.mkDerivation rec { <del> name = "ncompress-4.2.4.3"; </del> <ins> name = "ncompress-4.2.4.4"; </ins> builder = ./builder.sh;

src = fetchurl { url = "mirror://sourceforge/project/ncompress/${name}.tar.gz"; <del> sha256 = "1y44ixc1w2vfvj1lm4dkcljlwv882ynrvm5i6l0lg1gf883j246l"; </del> <ins> sha256 = "0yjiwv1hwb253x3m6r1dq2k7m5c9nz0ib2j7fnm3hark7y6s42xh"; </ins> }; meta = {
Change:
The default value for the path to the ACL points to the same path as the users file. Dokuwiki sees this as an invalid ACL, since the users file does not match the ACL syntax. This prevents users from logging in. Source: To Reproduce Expected behavior ACL is valid and users can log in. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:

Discussion:
aclFile = mkOption { type = with types; nullOr str; <del> default = if (config.aclUse && config.acl == null) then "/var/lib/dokuwiki/${name}/users.auth.php" else null; </del> <ins> default = if (config.aclUse && config.acl == null) then "/var/lib/dokuwiki/${name}/acl.auth.php" else null; </ins> description = '' Location of the dokuwiki acl rules. Mutually exclusive with services.dokuwiki.acl Mutually exclusive with services.dokuwiki.acl which is preferred.
Change:
The neovim wrapper tries to write to substitute file which is not present in macOS. This failure is probably related to <!-- This may be related to your recent rewrite. --Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:

Discussion:
in symlinkJoin { name = "neovim-${stdenv.lib.getVersion neovim}"; <ins> # Remove the symlinks created by symlinkJoin which we need to perform # extra actions upon </ins> postBuild = '' <del> # Remove the symlinks created by symlinkJoin which we need to perform # extra actions upon rm $out/share/applications/nvim.desktop $out/bin/nvim </del> <ins> rm $out/bin/nvim </ins> makeWrapper ${lib.escapeShellArgs initialMakeWrapperArgs} ${extraMakeWrapperArgs} <ins> '' + lib.optionalString stdenv.isLinux '' rm $out/share/applications/nvim.desktop </ins> substitute ${neovim}/share/applications/nvim.desktop $out/share/applications/nvim.desktop  --replace 'TryExec=nvim' "TryExec=$out/bin/nvim"  --replace 'Name=Neovim' 'Name=WrappedNeovim'
Change:
Project description C++ implementation of the HDT compression format Metadata homepage URL: source URL: license: lgpl3 platforms: linux
Pull request awaiting to be merged:

Discussion:
<ins> { stdenv, fetchFromGitHub, autoreconfHook, libtool, pkgconfig, zlib, serd }: stdenv.mkDerivation rec { pname = "hdt"; version = "1.3.3"; src = fetchFromGitHub { owner = "rdfhdt"; repo = "hdt-cpp"; rev = "v${version}"; sha256 = "1vsq80jnix6cy78ayag7v8ajyw7h8dqyad1q6xkf2hzz3skvr34z"; }; buildInputs = [ zlib serd ]; nativeBuildInputs = [ autoreconfHook libtool pkgconfig ]; enableParallelBuilding = true; meta = with stdenv.lib; { homepage = "http://www.rdfhdt.org/"; description = "Header Dictionary Triples (HDT) is a compression format for RDF data that can also be queried for Triple Patterns."; license = licenses.lgpl21; platforms = platforms.linux; maintainers = [ maintainers.koslambrou ]; }; } </ins>

haxor-news = callPackage ../applications/misc/haxor-news { }; <ins> hdt = callPackage ../misc/hdt {}; </ins> herqq = libsForQt5.callPackage ../development/libraries/herqq { }; heyefi = haskellPackages.heyefi;
Change:
Describe the bug The is failing. I bisected this problem to “linux: Init 5.8”. The error message matches , which points to both a workaround of recompiling systemd against Linux 5.8 headers, and an upstream systemd patch (systemd/systemd) that’s in systemd 246 () and was backported in 245.7 as systemd/systemd-stable To Reproduce Steps to reproduce the behavior: Notify maintainers Cc Metadata Please run and paste the result. Maintainer information:
My PR wasn't merged, Linux 5.8 ended up being by someone else.
Linking for visibility: that PR was
The PR bumping systemd to 245.7 is at
Is it really helpful to send systemd 245.7 to given that will be unable to advance without it? Or are you thinking we also want to revert the bump in for now?
Maybe we should revert in master, and re-revert it in staging again. I let and decide about this, they've been doing the staging rounds.
Hey all, question: How do you spot which tests block the channels? I always track and every few days I notice nixos-unstable doesn't progress. When it don't I see an issue with the "channel blocker" label and I always wonder..
Click on the “Hydra job for tests” link and go to the “Constituents” tab.

Discussion:
<del> { stdenv, buildPackages, fetchurl, perl, buildLinux, modDirVersionArg ? null, ... } @ args: with stdenv.lib; buildLinux (args // rec { version = "5.8"; # modDirVersion needs to be x.y.z, will automatically add .0 if needed modDirVersion = if (modDirVersionArg == null) then concatStringsSep "." (take 3 (splitVersion "${version}.0")) else modDirVersionArg; # branchVersion needs to be x.y extraMeta.branch = versions.majorMinor version; src = fetchurl { url = "mirror://kernel/linux/kernel/v5.x/linux-${version}.tar.xz"; sha256 = "1xgibkwb1yfl6qdlbxyagai0qc1pk5ark7giz1512hh6ma353xz7"; }; } // (args.argsOverride or {})) </del>

]; }; <del> linux_5_8 = callPackage ../os-specific/linux/kernel/linux-5.8.nix { kernelPatches = [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper kernelPatches.export_kernel_fpu_functions."5.3" ]; }; </del> linux_testing = callPackage ../os-specific/linux/kernel/linux-testing.nix { kernelPatches = [ kernelPatches.bridge_stp_helper

# Update this when adding the newest kernel major version! # And update linux_latest_for_hardened below if the patches are already available <del> linuxPackages_latest = linuxPackages_5_8; </del> <ins> linuxPackages_latest = linuxPackages_5_7; </ins> linux_latest = linuxPackages_latest.kernel; # Build the kernel modules for the some of the kernels.

linuxPackages_4_19 = recurseIntoAttrs (linuxPackagesFor pkgs.linux_4_19); linuxPackages_5_4 = recurseIntoAttrs (linuxPackagesFor pkgs.linux_5_4); linuxPackages_5_7 = recurseIntoAttrs (linuxPackagesFor pkgs.linux_5_7); <del> linuxPackages_5_8 = recurseIntoAttrs (linuxPackagesFor pkgs.linux_5_8); </del> # When adding to this list: # - Update linuxPackages_latest to the latest version
Change:
Synergy crashes without an X Display available, but the autostart option attempts to start synergy regardless of whether login is graphical or TTY. It would probably make more sense to spawn this after
(triage) status?
In case this is still relevant - would it make sense for those to run as user services instead to take advantage of recent changes merged in
I think this is probably still relevant, and I think your suggestion is probably a good one, . With this config: out of the box, I get the following: But if I kill the service and start the synergyc command manually as my unprivileged desktop user, it works just fine:

Discussion:
config = mkMerge [ (mkIf cfgC.enable { <del> systemd.services."synergy-client" = { after = [ "network.target" ]; </del> <ins> systemd.user.services."synergy-client" = { after = [ "network.target" "graphical-session.target" ]; </ins> description = "Synergy client"; <del> wantedBy = optional cfgC.autoStart "multi-user.target"; </del> <ins> wantedBy = optional cfgC.autoStart "graphical-session.target"; </ins> path = [ pkgs.synergy ]; serviceConfig.ExecStart = ''${pkgs.synergy}/bin/synergyc -f ${optionalString (cfgC.screenName != "") "-n ${cfgC.screenName}"} ${cfgC.serverAddress}''; serviceConfig.Restart = "on-failure"; }; }) (mkIf cfgS.enable { <del> systemd.services."synergy-server" = { after = [ "network.target" ]; </del> <ins> systemd.user.services."synergy-server" = { after = [ "network.target" "graphical-session.target" ]; </ins> description = "Synergy server"; <del> wantedBy = optional cfgS.autoStart "multi-user.target"; </del> <ins> wantedBy = optional cfgS.autoStart "graphical-session.target"; </ins> path = [ pkgs.synergy ]; serviceConfig.ExecStart = ''${pkgs.synergy}/bin/synergys -c ${cfgS.configFile} -f ${optionalString (cfgS.address != "") "-a ${cfgS.address}"} ${optionalString (cfgS.screenName != "") "-n ${cfgS.screenName}" }''; serviceConfig.Restart = "on-failure";
Change:
I'm not sure how to tackle this, but I recently updated my channels (unstable) and getting this issue with urwid (python2.7) after went in. Here's the logs just in case it's helpful to anyone: trying to build just that package fails in the same way: Notify maintainers Metadata
To my own dismay, this was circumvented in my system by disabling tests. However, again, in my system, the only reason I needed was because targetcli is hard set to build with python2. It would probably make sense to switch whatever made you hit this issue to py3 too.
this looks more like urwid doesn't support python2 for testing
isn't that what does? (disable tests on python2?). I tried to install the package with those modifications locally and worked. (Skipped tests). (for other newbies' future ref): I figured out the reason why was installed was as a dependency for . I'm not using , so just ended up removing wicd. was the command that helped me to figure it out.
I made a PR to disable the python2 tests, however, I'm not sure that upstream is checking the results of python2 anymore as the tests seemed to have issues decoding string correctly. This could be just the tests are python3 only, but I wouldn't use python2.... for anything right now

Discussion:
<del> { stdenv, buildPythonPackage, fetchPypi, glibcLocales }: </del> <ins> { stdenv, buildPythonPackage, isPy3k, fetchPypi, glibcLocales }: </ins> buildPythonPackage rec { pname = "urwid";

LC_ALL = "en_US.UTF-8"; checkInputs = [ glibcLocales ]; <ins> # tests which assert on strings don't decode results correctly doCheck = isPy3k; pythonImportsCheck = [ "urwid" ]; </ins> meta = with stdenv.lib; { description = "A full-featured console (xterm et al.) user interface library"; homepage = "http://excess.org/urwid";
Change:
Describe the bug Since the recent commit ( ledger fails to build on Darwin. To Reproduce or similar. Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(steve): channels(root): nixpkgs: Maintainer information:
if you don't need python. do you mind trying to build it with it off?
the error you're seeing is that a header from package isn't able to be found. I don't have a darwin machine to see why these two are different
Thanks. I don't need to work around it particularly, more interested in identifying a fix. I think the issue is that it's somehow picking up the system python: so probably some of the handling is broken, and indeed there are a few suspicious portions in the output I pasted, e.g. and subsequently:
I got the same cmake warnings, upstream needs to update some of their files. I'm not familiar enough with nix-darwin to have it NOT pull in system python

Discussion:
"-DCMAKE_INSTALL_LIBDIR=lib" "-DBUILD_DOCS:BOOL=ON" (lib.optionalString usePython "-DUSE_PYTHON=true") <ins> ] ++ lib.optionals (usePython && stdenv.isDarwin) [ # Fix python lookup on Darwin. Not necessary after # https://github.com/NixOS/nixpkgs/pull/94090 lands in master "-DPython_ROOT_DIR=${python}" </ins> ]; # by default, it will query the python interpreter for it's sitepackages location