jiebi/CodeConvo huggingface dataset:
Change:
On Darwin the wrapper adds a number of unused arguments that are passed along to . displays a warning for each of these arguments: This makes the build log of some packages extremely large, and in turn it can cause because of the log size limit is exceeded. /cc system: host os: multi-user?: sandbox: version: channels(smaret): nixpkgs:
I think that fortran on darwin is a rather under-maintained combination in nixpkgs ATM.
for packages that use and on Darwin: Could this be implemented in the wrapper itself rather than in each package that uses the wrapper?
This needs to be propagated to everything that uses gfortran? I think using for gfortran packages might be a better in that case, it's less likely to cause other problems.
I think auto-passing such an option is slightly risky over the long term, as it may hide other errors, e.g. user typos. (No strong opinion.) I wonder if using gfortran with clang is actually a "supported" combination upstream; I guess might be better, as you write.

Discussion:
buildInputs = [ gtk2-x11 lesstif cfitsio python27Env ]; <del> patches = [ ./wrapper.patch ./return-error-code.patch ./clang.patch ./aarch64.patch ]; </del> <ins> patches = [ ./wrapper.patch ./return-error-code.patch ./clang.patch ./aarch64.patch ./gag-font-bin-rule.patch ]; NIX_CFLAGS_COMPILE = stdenv.lib.optionalString stdenv.cc.isClang "-Wno-unused-command-line-argument"; </ins> configurePhase='' substituteInPlace admin/wrapper.sh --replace '%%OUT%%' $out

<ins> diff -ruN gildas-src-aug18a/kernel/etc/Makefile gildas-src-aug18a.gag-font-bin-rule/kernel/etc/Makefile --- gildas-src-aug18a/kernel/etc/Makefile	2016-09-09 09:39:37.000000000 +0200 +++ gildas-src-aug18a.gag-font-bin-rule/kernel/etc/Makefile	2018-09-04 12:03:11.000000000 +0200 @@ -29,7 +29,8 @@ SEDEXE=sed -e 's?source tree?executable tree?g' -$(datadir)/gag-font.bin: hershey-font.dat $(bindir)/hershey +$(datadir)/gag-font.bin: hershey-font.dat $(bindir)/hershey  +	$(gagintdir)/etc/gag.dico.gbl $(gagintdir)/etc/gag.dico.lcl ifeq ($(GAG_ENV_KIND)-$(GAG_TARGET_KIND),cygwin-mingw) $(bindir)/hershey `cygpath -w $(datadir)`/gag-font.bin else </ins>
Change:
It's interesting that this doesn't happen on (x86_64-)linux, apparently.

Discussion:
stdenv.lib.optional crossCompiling "dev"; setOutputFlags = false; <ins> disallowedReferences = [ stdenv.cc ]; </ins> patches = [ ] # Do not look in /usr etc. for dependencies.

--replace "${ if stdenv.cc.cc or null != null then stdenv.cc.cc else "/no-such-path" }" /no-such-path  <ins> --replace "${stdenv.cc}" /no-such-path  </ins> --replace "$man" /no-such-path '' + stdenv.lib.optionalString crossCompiling ''
Change:
Attempt to use libepoxy gives See
Repro: Expected: the game window pops up Actual:
That's not epoxy, but glfw problem. ALthough I would like to make PR with fixing glfw, and bump epoxy version as well.
Do we need this in 18.09 as well?
I feel it good idea (is a minor version update, no major bump), and looks no breakages from it (At least firefox built ok and runs on it. I tested only switch on my test host, not full reboot after switch). But I can't prove, if it still need full paths everywhere or not. (I have some doubts about vs hardwire full paths to libraries). Need find something, using epoxy and not glfw as test subject.
I just updated to and the problem persists.

Discussion:
cmakeFlags = [ "-DBUILD_SHARED_LIBS=ON" ]; <ins> preConfigure  = lib.optional (!stdenv.isDarwin) '' substituteInPlace src/glx_context.c --replace "libGL.so.1" "${lib.getLib libGL}/lib/libGL.so.1" ''; </ins> meta = with stdenv.lib; { description = "Multi-platform library for creating OpenGL contexts and managing input, including keyboard, mouse, joystick and time"; homepage = http://www.glfw.org/;
Change:
In commit was to the hackage package set, which splits up into However, instead of updating the hash of the original derivation, a new derivation was introduced named and all the packages now wrongly depend on instead of , breaking the builds. I'm not very familiar with the whole tooling, so I'm wonderng why it created a new package instead of updating the existing one? And how would I make update the original package, instead of creating a new derivation name? CC This is currently blocking
I think I found out why. It's because of this line. if I just change that file, will it work as expected again?
isn't in any Stackage LTS snapshot yet. so another option we could choose is to remove the packages for now.
The whole package set is based on some Stackage LTS the 0.6 version remains the default and the 0.7 version is opt-in. The way to fix this is to modify and add something like

Discussion:
# https://github.com/snapframework/xmlhtml/pull/37 xmlhtml = doJailbreak super.xmlhtml; <ins> # https://github.com/NixOS/nixpkgs/issues/46467 safe-money-aeson = super.safe-money-aeson.override { safe-money = self.safe-money_0_7; }; safe-money-store = super.safe-money-store.override { safe-money = self.safe-money_0_7; }; safe-money-cereal = super.safe-money-cereal.override { safe-money = self.safe-money_0_7; }; safe-money-serialise = super.safe-money-serialise.override { safe-money = self.safe-money_0_7; }; safe-money-xmlbf = super.safe-money-xmlbf.override { safe-money = self.safe-money_0_7; }; </ins> } // import ./configuration-tensorflow.nix {inherit pkgs haskellLib;} self super
Change:
nixos/modules/services/x11/display- has code to load ~/.Xdefaults, but not ~/.Xresources, even though ~/.Xdefaults is the deprecated version of ~/.Xresources

Discussion:
''} # Load X defaults. <del> if test -e ~/.Xdefaults; then </del> <ins> if test -e ~/.Xresources; then ${xorg.xrdb}/bin/xrdb -merge ~/.Xresources elif test -e ~/.Xdefaults; then </ins> ${xorg.xrdb}/bin/xrdb -merge ~/.Xdefaults fi
Change:
nixos/modules/services/x11/display- has code to load ~/.Xdefaults, but not ~/.Xresources, even though ~/.Xdefaults is the deprecated version of ~/.Xresources

Discussion:
python3.pkgs.buildPythonApplication rec { pname = "borgbackup"; <del> version = "1.1.10"; </del> <ins> version = "1.1.11"; </ins> src = python3.pkgs.fetchPypi { inherit pname version; <del> sha256 = "1pp70p4n5kamvcbl4d8021ggrxhyykmg9isjg4yd3wags8b19d7g"; </del> <ins> sha256 = "190gjzx83b6p64nqj840x382dgz9gfv0gm7wj585lnkrpa90j29n"; </ins> }; nativeBuildInputs = with python3.pkgs; [

HOME=$(mktemp -d) py.test --pyargs borg.testsuite ''; <del> # 63 failures, needs pytest-benchmark </del> <ins> # 64 failures, needs pytest-benchmark </ins> doCheck = false; meta = with stdenv.lib; {
Change:
Current way to install new printers () is not really the thing user will figure out without a manual, and I think we might try to do better. Maybe add a list of installed PPDs to services.printing or something like that, but I don't really know how CUPS finds or stores PPDs, so I don't know if this really can be made better.
There are two things that tripped me: obvious way how to use gutenprint in the docs (for someone not familiar with how cups works) the helped the naïve way (installing gutenprint as package) doesn’t work and it doesn’t tell you why generating the ppds is necessary. If possible, this should be done automatically while realizing the derivation Does it take too much storage?
When I my printer again recently, the gutenprint ppds where directly accessible from the interface, so all one has to do now is add gutenprint to . I just noticed there is now. Huzzah!
Oh, I fixed that by myself recently and forgot. Let's close!

Discussion:
example = literalExample "[ pkgs.splix ]"; description = '' CUPS drivers to use. Drivers provided by CUPS, cups-filters, Ghostscript <del> and Samba are added unconditionally. </del> <ins> and Samba are added unconditionally. For adding Gutenprint, see <literal>gutenprint</literal>. </ins> ''; };
Change:
Reported in -- couldn't find another relevant issue. The test stopped working after First failing run: It appears that the veth is no longer properly associated with the bridge after reconfiguration.
During reconfiguration the bridge interface is destroyed and then recreated with the same name but a new interface id (while the container network namespace is unchanged): Initial: After switching config:
I wonder if we should just let manage container networking. It is supposed to work pretty much out of the box with containers.
Here's what happens in terms of systemd units: restarts (makes sense) -stop due to the relationship introduced in . -stop due to a (correct) dependency. removes the interface despite the container veth is still associated with it.
I don't understand step 2. Why restart the entire networking setup because one address has changed? But we can't just revert because that it fixed a nixops bug unrelated to bridge interfaces. As a hack, we could skip deleting the bridge if a container veth is still associated with it.

Discussion:
after = [ "network-pre.target" "systemd-udevd.service" "systemd-sysctl.service" ]; before = [ "network.target" "shutdown.target" ]; wants = [ "network.target" ]; <del> partOf = map (i: "network-addresses-${i.name}.service") interfaces; </del> <ins> # exclude bridges from the partOf relationship to fix container networking bug #47210 partOf = map (i: "network-addresses-${i.name}.service") (filter (i: !(hasAttr i.name cfg.bridges)) interfaces); </ins> conflicts = [ "shutdown.target" ]; wantedBy = [ "multi-user.target" ] ++ optional hasDefaultGatewaySet "network-online.target";
Change:
Travis has been giving build failures because of this: commit seems to be at fault here.. The reason I didn't just fix this this bug and push upstream is because there are two different ways to approach this and I'm not sure which the best course of action is. a) jfsrec removal was intentional, remove all references to jfsrec b) restore jfsrec Here is a listing of all current things pointing to jfsrec:
The jfsrec commit has already been reverted.
thanks for the info

Discussion:
python3.pkgs.buildPythonApplication rec { pname = "borgbackup"; <del> version = "1.1.10"; </del> <ins> version = "1.1.11"; </ins> src = python3.pkgs.fetchPypi { inherit pname version; <del> sha256 = "1pp70p4n5kamvcbl4d8021ggrxhyykmg9isjg4yd3wags8b19d7g"; </del> <ins> sha256 = "190gjzx83b6p64nqj840x382dgz9gfv0gm7wj585lnkrpa90j29n"; </ins> }; nativeBuildInputs = with python3.pkgs; [

HOME=$(mktemp -d) py.test --pyargs borg.testsuite ''; <del> # 63 failures, needs pytest-benchmark </del> <ins> # 64 failures, needs pytest-benchmark </ins> doCheck = false; meta = with stdenv.lib; {
Change:
Build The patch URL in pkgs/development/python- should maybe refer to a specific commit?
This URL seems to work to get the old patch, if that's the intention:
Fixed by , assuming the desire is to continue using the old version of the patch.

Discussion:
patches = fetchpatch { name = "cheroot-fix-setup-python3.patch"; <del> url = "https://git.archlinux.org/svntogit/community.git/plain/trunk/cheroot-fix-setup-python3.patch?h=packages/python-cheroot"; </del> <ins> url = "https://git.archlinux.org/svntogit/community.git/plain/trunk/cheroot-fix-setup-python3.patch?h=packages/python-cheroot&id=9b33cb0885b3c0d91adeacae23761a4321eb0e64"; </ins> sha256 = "1rlgz0qln536y00mfqlf0i9hz3f53id73wh47cg5q2vcsw1w2bpc"; };
Change:
Reproducing is pretty simple: . The error is: system: host os: multi-user?: sandbox: version: channels(philipp): channels(root): nixpkgs:

Discussion:
''; }; <ins> jshint = nodePackages.jshint.override { buildInputs = [ pkgs.phantomjs2 ]; }; </ins> dat = nodePackages.dat.override { buildInputs = [ nodePackages.node-gyp-build ]; };
Change:
The .nix for Gitkraken specifies a like , which now seems to give me a 404. Their links to files like fwiw, but I'm not yet sure where the pinned versions might not be hosted... install gitkraken using nixpkgs
New version and moved url, the correct url seems to be

Discussion:
in stdenv.mkDerivation rec { name = "gitkraken-${version}"; <del> version = "4.0.2"; </del> <ins> version = "4.0.5"; </ins> src = fetchurl { <del> url = "https://release.gitkraken.com/linux/v${version}.deb"; sha256 = "0dnckd75fcgc9wa4ivbnw2djmk4phzzr891snhxpsvb1dhlc7rgx"; </del> <ins> url = "https://release.axocdn.com/linux/GitKraken-v${version}.deb"; sha256 = "15wxcahlnz2k3331wqv30d5gq38fqh178hv87xky9b9vyh8qpcvz"; </ins> }; libPath = makeLibraryPath [
Change:
The NixOS syncthing service with default settings sets (where $HOME is /var/lib/syncthing) and with that breaks upstream assumption: The result is that you cannot run syncthing with (nixos) default settings and give access to various users with ACLs, as syncthing will set perms 700 on the directory passed in each time it starts. And as is the same as , your default shared folders are now hidden behind 700 perms. Workaround (hack): Based on , the fix seems to be simply setting instead of . and ACL: that your user has access: syncthing: no longer have access to the share: system: host os: multi-user?: sandbox: version: channels(root): channels(bfo): nixpkgs:
The fix is easy but it will break all existing setups. We could add a and mention it in the release changes.

Discussion:
start org.nixos.nix-daemon</command>. </para> </listitem> <ins> <listitem> <para> The Syncthing state and configuration data has been moved from <varname>services.syncthing.dataDir</varname> to the newly defined <varname>services.syncthing.configDir</varname>, which default to <literal>/var/lib/syncthing/.config/syncthing</literal>. This change makes possible to share synced directories using ACLs without Syncthing resetting the permission on every start. </para> </listitem> </ins> </itemizedlist> </listitem> <listitem>

type = types.path; default = "/var/lib/syncthing"; description = '' <ins> Path where synced directories will exist. ''; }; configDir = mkOption { type = types.path; description = '' </ins> Path where the settings and keys will exist. ''; <ins> default = let nixos = config.system.stateVersion; cond  = versionAtLeast nixos "19.03"; in cfg.dataDir + (optionalString cond "/.config/syncthing"); </ins> }; openDefaultPorts = mkOption {

${cfg.package}/bin/syncthing  -no-browser  -gui-address=${cfg.guiAddress}  <del> -home=${cfg.dataDir} </del> <ins> -home=${cfg.configDir} </ins> ''; }; };
Change:
The latest version of Emby is only available in the dotnet core version : I can't find any documentation on how to package a dotnet app in NixOS. Help would be much appreciated ! I found that the dotnet-sdk package is providing the dotnet executable, is it a simple swap between mono and this ?
I am interested in using dotnet with nixpkgs. The dotnet-sdk is up to date and can build and run applications but there is also , which is just the runtime. It might be a good practice to use dotnet-sdk for building but build the wrapper with coreclr. This should result in smaller runtime closures. There is also which is actually using mono.

Discussion:
<del> { stdenv, fetchurl, unzip, sqlite, makeWrapper, mono54, ffmpeg }: </del> <ins> { stdenv, fetchurl, unzip, sqlite, makeWrapper, dotnet-sdk, ffmpeg }: </ins> stdenv.mkDerivation rec { name = "emby-${version}"; <del> version = "3.5.2.0"; </del> <ins> version = "3.5.3.0"; </ins> # We are fetching a binary here, however, a source build is possible. # See -> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=emby-server-git#n43

# This may also need msbuild (instead of xbuild) which isn't in nixpkgs # See -> https://github.com/NixOS/nixpkgs/issues/29817 src = fetchurl { <del> url = "https://github.com/MediaBrowser/Emby.Releases/releases/download/${version}/embyserver-mono_${version}.zip"; sha256 = "12f9skvnr9qxnrvr3q014yggfwvkpjk0ynbgf0fwk56h4kal7fx8"; </del> <ins> url = "https://github.com/MediaBrowser/Emby.Releases/releases/download/${version}/embyserver-netcore_${version}.zip"; sha256 = "0311af3q813cx0ykbdk9vkmnyqi2l8rx66jnvdkw927q6invnnpj"; </ins> }; buildInputs = [

]; propagatedBuildInputs = [ <del> mono54 </del> <ins> dotnet-sdk </ins> sqlite ]; preferLocalBuild = true; <del> # Need to set sourceRoot as unpacker will complain about multiple directory output sourceRoot = "."; </del> buildPhase = '' <del> substituteInPlace SQLitePCLRaw.provider.sqlite3.dll.config --replace libsqlite3.so ${sqlite.out}/lib/libsqlite3.so substituteInPlace MediaBrowser.Server.Mono.exe.config --replace ProgramData-Server "/var/lib/emby/ProgramData-Server" </del> <ins> rm -rf {electron,runtimes} </ins> ''; installPhase = '' <del> mkdir -p "$out/bin" cp -r * "$out/bin" makeWrapper "${mono54}/bin/mono" $out/bin/MediaBrowser.Server.Mono  --add-flags "$out/bin/MediaBrowser.Server.Mono.exe -ffmpeg ${ffmpeg}/bin/ffmpeg -ffprobe ${ffmpeg}/bin/ffprobe" </del> <ins> install -dm 755 "$out/opt/emby-server" cp -r * "$out/opt/emby-server" makeWrapper "${dotnet-sdk}/bin/dotnet" $out/bin/emby  --prefix LD_LIBRARY_PATH : "${stdenv.lib.makeLibraryPath [ sqlite ]}"  --add-flags "$out/opt/emby-server/EmbyServer.dll -programdata /var/lib/emby/ProgramData-Server -ffmpeg ${ffmpeg}/bin/ffmpeg -ffprobe ${ffmpeg}/bin/ffprobe" </ins> ''; meta =  with stdenv.lib; {
Change:
The current wxmac port fails to build. Build wxmac from latest git. wxWidgets uses some deprecated CoreFoundation functions, which are no longer there. Upstream version 3.0.4 still uses these functions. Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(sperber): nixpkgs:
That's very annoying! There has been a recent update of CF by that uses CF from Apparently they don't implement these deprecated APIs. We should be able to patch it to fix these references and use updated APIs. For now though you will probably be stuck on 18.03 or 18.09 if you need wxmac.
Yeah, I looked into that for a while, but the references to the now-unsupported FSRef type are pretty widespread in the wxmac codebase. :-( (I don't need wxmac directly, but erlang depends on it.)
Yeah, I patched those calls out of QT 4 but haven't gone and looked for other stuff that uses them.
Looking at source, it doesn't look like those functions are really used in any essential way. If you look at who calls , it doesn't really seem to be used anywhere much, and is used to set some icons. Or vice versa, but either way doesn't seem like it would be hard to patch out.
I was thinking the same thing, but my impression was that these are part of the public API of wxWidgets.
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 .

Discussion:
, enableKernelPoll ? true , javacSupport ? false, javacPackages ? [ openjdk ] , odbcSupport ? false, odbcPackages ? [ unixODBC ] <del> , wxSupport ? true, wxPackages ? [ libGLU_combined wxGTK xorg.libX11 ] </del> <ins> , wxSupport ? !stdenv.isDarwin, wxPackages ? [ libGLU_combined wxGTK xorg.libX11 ] </ins> , preUnpack ? "", postUnpack ? "" , patches ? [], patchPhase ? "", prePatch ? "", postPatch ? "" , configureFlags ? [], configurePhase ? "", preConfigure ? "", postConfigure ? ""
Change:
I cannot build pytorch (cuda enabled or disabled), due to failing tests. I'm not sure why this is built locally instead of taken from the cache. I expect to get a shell where can be run and can be imported. Instead, I get an error: Full log is too long for pastebin, but the errors mostly look like: With these probably relevant lines near the beginning: Those two files both contain in my user shell.
I think it might be a sandboxing thing. Could you try running with ?
That doesn't help, I still get the same error with However, a sample nix that just does as its also fails: : Am I doing something wrong here?
Oops, I think you do need to be a "trusted user" to disable sandbox. You can try it by running: (or adding your user to nix.trustedUsers)
Yes, that works. Is there anything I can do to fix the package for other users? I could disable the problematic tests (I think they were enabled in ), or is there some way of saying a package must be built without sandboxing? Or only to run certain tests if sandboxing is disabled?
Yes, that works for pytorch but not for pytorchWithCuda: I tried using nixos-unstable and the PR but I got the same error. Any idea ?
I have in my - can you see if you see if it works for you then? If yes, I think there is some other package that needs with cuda enabled but it doesn't correctly depend on.
Tried with but same error. Tensorflow and tensorflowWithCuda work with my config.
Adding cudnn solved the problem. :champagne:
It is very odd that your initial command works for me without problems:
Indeed, I get lost in the different configurations that I tried. with works fine. Thanks.

Discussion:
] ++ lib.optional (pythonOlder "3.5") typing; checkPhase = '' <del> ${cudaStubEnv}python test/run_test.py --exclude dataloader sparse torch utils </del> <ins> ${cudaStubEnv}python test/run_test.py --exclude dataloader sparse torch utils distributed </ins> ''; meta = {
Change:
Monero is hardforking and changing the proof of work. xmr-stak must be upgraded to v2.5.0 before the 18th of Oct (Thu), or it will stop working Thanks
Thanks & .. When can we expect this to land ? Thanks
It should be ready to merge already.

Discussion:
, qtlocation, qtquickcontrols2, qtwebchannel , qtwebengine, qtx11extras, qtxmlpatterns , monero, unbound, readline, boost, libunwind <del> , pcsclite, zeromq, cppzmq, pkgconfig </del> <ins> , libsodium, pcsclite, zeromq, cppzmq, pkgconfig </ins> }: with stdenv.lib; stdenv.mkDerivation rec { name = "monero-gui-${version}"; <del> version = "0.12.3.0"; </del> <ins> version = "0.13.0.2"; </ins> src = fetchFromGitHub { owner  = "monero-project"; repo   = "monero-gui"; rev    = "v${version}"; <del> sha256 = "1ry0455cgirkc6n46qnlv5p49axjllil78xmx6469nbp3a2r3z7i"; </del> <ins> sha256 = "02419rqi3zfy6yjyw3b3gvkbxh2ypdfpijiiklc7lyblb9nnjr68"; </ins> }; nativeBuildInputs = [ qmake pkgconfig ];

qtdeclarative qtlocation qtquickcontrols2 qtwebchannel qtwebengine qtx11extras qtxmlpatterns monero unbound readline <del> boost libunwind pcsclite zeromq cppzmq makeWrapper </del> <ins> boost libunwind libsodium pcsclite zeromq cppzmq makeWrapper </ins> ]; patches = [

{ stdenv, fetchgit , cmake, pkgconfig, git , boost, miniupnpc, openssl, unbound, cppzmq <del> , zeromq, pcsclite, readline </del> <ins> , zeromq, pcsclite, readline, libsodium </ins> , CoreData, IOKit, PCSC }:

stdenv.mkDerivation rec { name    = "monero-${version}"; <del> version = "0.12.3.0"; </del> <ins> version = "0.13.0.2"; </ins> src = fetchgit { url    = "https://github.com/monero-project/monero.git"; rev    = "v${version}"; <del> sha256 = "1609k1qn9xx37a92ai36rajds9cmdjlkqyka95hks5xjr3l5ca8i"; </del> <ins> sha256 = "078iw76ajvaj08rgnx3c13pnq8fxah1z9wwyz54fcnj2349sjbf5"; </ins> }; nativeBuildInputs = [ cmake pkgconfig git ];

buildInputs = [ boost miniupnpc openssl unbound cppzmq zeromq pcsclite readline <ins> libsodium </ins> ] ++ optionals stdenv.isDarwin [ IOKit CoreData PCSC ]; cmakeFlags = [

stdenv'.mkDerivation rec { name = "xmr-stak-${version}"; <del> version = "2.4.7"; </del> <ins> version = "2.5.0"; </ins> src = fetchFromGitHub { owner = "fireice-uk"; repo = "xmr-stak"; rev = "${version}"; <del> sha256 = "072gapchmd05ir5ygrvbgdhpjhm7pdjyl61n1ykxzvnvi81z6817"; </del> <ins> sha256 = "1qls0rai9c1cszcqqqmhcdvcsmm23w1jxzlq2b035apkz7ywbxjl"; </ins> }; NIX_CFLAGS_COMPILE = "-O3";