jiebi/CodeConvo huggingface dataset:
Code change:
Describe the bug On NixOS 20.09 and unstable, is not in the search path, even though it is installed with the php package. To Reproduce Steps to reproduce the behavior: [example from 20.09 system] Expected behavior [example from 20.03 system] Additional context Debugging with reveals that on 20.09, php is searching in , then , which fails. On 20.03, it searches in , then , which succeeds. On 20.09 and unstable, php74 and php73 both fail. On 20.03, php73 (the default) works, but php74 fails, but I believe it fails for a different reason. This line is new since release-20.03. At first glance, it seems as though is resolving to null here, but I'm not sure what to replace it with: Notify maintainers Metadata Maintainer information:
Thanks for reporting this issue! Your guess was right on spot and it was a really simple fix it seems :slightlysmilingface: As you may have seen: Right after 20.03 branched off we started a big refactoring of the PHP ecosystem. So bugs and issues was to be expected :slightlysmilingface:

Related discussion:
text: ++ lib.optional (!cgiSupport) "--disable-cgi" ++ lib.optional (!cliSupport) "--disable-cli" ++ lib.optional fpmSupport    "--enable-fpm" <del> ++ lib.optional pearSupport [ "--with-pear=$(out)/lib/php/pear" "--enable-xml" "--with-libxml" ] </del> <ins> ++ lib.optional pearSupport [ "--with-pear" "--enable-xml" "--with-libxml" ] </ins> ++ lib.optionals (pearSupport && (lib.versionOlder version "7.4")) [ "--enable-libxml" "--with-libxml-dir=${libxml2.dev}"
Code change:
I'm using the example of which renders correctly in firefox (the text in that section matches the image), but not in chromium (I see some placeholder boxes) my font configuration is exactly that given in I'm running nixos-unstable. I don't have flash enabled, or any other modifications to the default chromium package. From a bit of research, I've found that it might be the case that chromium restricts access to system fonts in some way, as a privacy aid - possibly that is to blame. Note: this occurs without any addons (running chromium as )

Related discussion:
text: {stdenv, fetchurl}: stdenv.mkDerivation rec { <del> name = "ncompress-4.2.4.3"; </del> <ins> name = "ncompress-4.2.4.4"; </ins> builder = ./builder.sh;
Code change:
I'm using the example of which renders correctly in firefox (the text in that section matches the image), but not in chromium (I see some placeholder boxes) my font configuration is exactly that given in I'm running nixos-unstable. I don't have flash enabled, or any other modifications to the default chromium package. From a bit of research, I've found that it might be the case that chromium restricts access to system fonts in some way, as a privacy aid - possibly that is to blame. Note: this occurs without any addons (running chromium as )

Related discussion:
text: src = fetchurl { url = "mirror://sourceforge/project/ncompress/${name}.tar.gz"; <del> sha256 = "1y44ixc1w2vfvj1lm4dkcljlwv882ynrvm5i6l0lg1gf883j246l"; </del> <ins> sha256 = "0yjiwv1hwb253x3m6r1dq2k7m5c9nz0ib2j7fnm3hark7y6s42xh"; </ins> }; meta = {
Code change:
, CVSSv3=8.8 (nixos-20.03, nixos-20.09, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-20.09: ; nixos-unstable: . Cc

Related discussion:
text: { stdenv, fetchurl, pkgconfig, yasm <del> , freetype, fribidi </del> <ins> , freetype, fribidi, harfbuzz </ins> , encaSupport ? true, enca ? null # enca support , fontconfigSupport ? true, fontconfig ? null # fontconfig support <del> , harfbuzzSupport ? true, harfbuzz ? null # harfbuzz support </del> , rasterizerSupport ? false # Internal rasterizer , largeTilesSupport ? false # Use larger tiles in the rasterizer , libiconv
Code change:
, CVSSv3=8.8 (nixos-20.03, nixos-20.09, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-20.09: ; nixos-unstable: . Cc

Related discussion:
text: assert encaSupport -> enca != null; assert fontconfigSupport -> fontconfig != null; <del> assert harfbuzzSupport -> harfbuzz != null; </del> let mkFlag = optSet: flag: if optSet then "--enable-${flag}" else "--disable-${flag}";
Code change:
, CVSSv3=8.8 (nixos-20.03, nixos-20.09, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-20.09: ; nixos-unstable: . Cc

Related discussion:
text: with stdenv.lib; stdenv.mkDerivation rec { pname = "libass"; <del> version = "0.14.0"; </del> <ins> version = "0.15.0"; </ins> src = fetchurl { url = "https://github.com/libass/libass/releases/download/${version}/${pname}-${version}.tar.xz"; <del> sha256 = "18iqznl4mabhj9ywfsz4kwvbsplcv1jjxq50nxssvbj8my1267w8"; </del> <ins> sha256 = "0cz8v6kh3f2j5rdjrra2z0h715fa16vjm7kambvqx9hak86262cz"; </ins> }; configureFlags = [ (mkFlag encaSupport "enca") (mkFlag fontconfigSupport "fontconfig") <del> (mkFlag harfbuzzSupport "harfbuzz") </del> (mkFlag rasterizerSupport "rasterizer") (mkFlag largeTilesSupport "large-tiles") ]; nativeBuildInputs = [ pkgconfig yasm ]; <del> buildInputs = [ freetype fribidi ] </del> <ins> buildInputs = [ freetype fribidi harfbuzz ] </ins> ++ optional encaSupport enca ++ optional fontconfigSupport fontconfig <del> ++ optional harfbuzzSupport harfbuzz </del> ++ optional stdenv.isDarwin libiconv; meta = {
Code change:
With NixOS 15.09 I get this error running LilyPond: I can work around this (clumsily) by using an old version of in LilyPond's . This differs by not including . This seems to be related to Changing apparently can break some users of as well as those of .
cc
Hmm, perhaps we should add or some similar option to handle these cases easily?
It's better to set in most cases, which I just did in and .

Related discussion:
text: {stdenv, fetchurl}: stdenv.mkDerivation rec { <del> name = "ncompress-4.2.4.3"; </del> <ins> name = "ncompress-4.2.4.4"; </ins> builder = ./builder.sh;
Code change:
With NixOS 15.09 I get this error running LilyPond: I can work around this (clumsily) by using an old version of in LilyPond's . This differs by not including . This seems to be related to Changing apparently can break some users of as well as those of .
cc
Hmm, perhaps we should add or some similar option to handle these cases easily?
It's better to set in most cases, which I just did in and .

Related discussion:
text: src = fetchurl { url = "mirror://sourceforge/project/ncompress/${name}.tar.gz"; <del> sha256 = "1y44ixc1w2vfvj1lm4dkcljlwv882ynrvm5i6l0lg1gf883j246l"; </del> <ins> sha256 = "0yjiwv1hwb253x3m6r1dq2k7m5c9nz0ib2j7fnm3hark7y6s42xh"; </ins> }; meta = {
Code change:
Describe the bug defines the CMake path. The environment variable is included in this, and addons like SDL2mixer append themselves to this path. However, that same file also defines an target, which does not include in its include directories. See for an example of an issue caused by this. To Reproduce Steps to reproduce the behavior: to build an application relying on SDL2::SDL2 adding SDL2mixer to the include path, such as Expected behavior 's should include the environment variable, just like . Screenshots N/A Additional context N/A Notify maintainers (SDL2), (SDL2mixer) Metadata Maintainer information:

Related discussion:
text: <del> diff -ru3 SDL2-2.0.4/sdl2-config.cmake.in SDL2-2.0.4-new/sdl2-config.cmake.in --- SDL2-2.0.4/sdl2-config.cmake.in	2016-01-02 22:56:31.000000000 +0300 +++ SDL2-2.0.4-new/sdl2-config.cmake.in	2016-08-22 05:26:42.420397323 +0300 @@ -6,5 +6,6 @@ </del> <ins> diff -ru3 SDL2-2.0.12/sdl2-config.cmake.in SDL2-2.0.12-new/sdl2-config.cmake.in --- SDL2-2.0.12/sdl2-config.cmake.in	2020-03-11 02:36:18.000000000 +0100 +++ SDL2-2.0.12-new/sdl2-config.cmake.in	2020-11-11 11:59:05.178703826 +0100 @@ -6,7 +6,8 @@ </ins> set(SDL2_PREFIX "@prefix@") set(SDL2_EXEC_PREFIX "@prefix@") set(SDL2_LIBDIR "@libdir@")
Code change:
Describe the bug defines the CMake path. The environment variable is included in this, and addons like SDL2mixer append themselves to this path. However, that same file also defines an target, which does not include in its include directories. See for an example of an issue caused by this. To Reproduce Steps to reproduce the behavior: to build an application relying on SDL2::SDL2 adding SDL2mixer to the include path, such as Expected behavior 's should include the environment variable, just like . Screenshots N/A Additional context N/A Notify maintainers (SDL2), (SDL2mixer) Metadata Maintainer information:

Related discussion:
text: +set(SDL2_INCLUDE_DIRS "@includedir@/SDL2" $ENV{SDL2_PATH}) +separate_arguments(SDL2_INCLUDE_DIRS) set(SDL2_LIBRARIES "-L${SDL2_LIBDIR} @SDL_RLD_FLAGS@ @SDL_LIBS@") <del> diff -ru3 SDL2-2.0.4/sdl2-config.in SDL2-2.0.4-new/sdl2-config.in --- SDL2-2.0.4/sdl2-config.in	2016-01-02 22:56:31.000000000 +0300 +++ SDL2-2.0.4-new/sdl2-config.in	2016-08-22 05:32:02.256397839 +0300 </del> <ins> string(STRIP "${SDL2_LIBRARIES}" SDL2_LIBRARIES) @@ -20,14 +21,14 @@ add_library(SDL2::SDL2 SHARED IMPORTED) set_target_properties(SDL2::SDL2 PROPERTIES -    INTERFACE_INCLUDE_DIRECTORIES "@includedir@/SDL2" +    INTERFACE_INCLUDE_DIRECTORIES "${SDL2_INCLUDE_DIRS}" IMPORTED_LINK_INTERFACE_LANGUAGES "C" IMPORTED_LOCATION "@libdir@/libSDL2.so" INTERFACE_LINK_LIBRARIES "${SDL2_EXTRA_LINK_FLAGS}") add_library(SDL2::SDL2-static STATIC IMPORTED) set_target_properties(SDL2::SDL2-static PROPERTIES -    INTERFACE_INCLUDE_DIRECTORIES "@includedir@/SDL2" +    INTERFACE_INCLUDE_DIRECTORIES "${SDL2_INCLUDE_DIRS}" IMPORTED_LINK_INTERFACE_LANGUAGES "C" IMPORTED_LOCATION "@libdir@/libSDL2.a" INTERFACE_LINK_LIBRARIES "${SDL2_EXTRA_LINK_FLAGS_STATIC}") Només a SDL2-2.0.12-new/: sdl2-config.cmake.in.orig diff -ru3 SDL2-2.0.12/sdl2-config.in SDL2-2.0.12-new/sdl2-config.in --- SDL2-2.0.12/sdl2-config.in	2020-03-11 02:36:18.000000000 +0100 +++ SDL2-2.0.12-new/sdl2-config.in	2020-11-11 11:56:26.432955479 +0100 </ins> @@ -42,7 +42,11 @@ echo @SDL_VERSION@ ;;
Code change:
Experienced on gnome3.38 which is currently on master. alacritty 0.5.0 isn't functional at all. 0.6.0rc-1 is. Should we update in order to make our packages set functional? Or should we wait for a real, no rc release upstream?
you should update yourself in the maintainers list - I had to go to to see who is .
Is this a wayland issue on gnome?
Yes.
Sound fine to me.
Thanks for pointing this out. As much as I want to see my first username long gone, the change was not worth it :)

Related discussion:
text: in rustPlatform.buildRustPackage rec { pname = "alacritty"; <del> version = "0.5.0"; </del> <ins> # 0.5.0 is not compatible with gnome 3.38 version = "0.6.0-rc1"; </ins> src = fetchFromGitHub { owner = "alacritty"; repo = pname; rev = "v${version}"; <del> sha256 = "1948j57xhqvc5y876s929x9rhd6j0xnw5c91g1zqw2rfncn602g2"; </del> <ins> sha256 = "RuIJvB0J/BQFqemOkEUiqS1uz0gMS49Dd8UQt0nbrQ0="; </ins> }; <del> cargoSha256 = "17lyzcj07f0vyki3091vgjd0w8ki11sw5m8gb3bxdph1dl04rria"; </del> <ins> cargoSha256 = "+3iZywLvy+8C7j6g9bqij2DSLjBoE2u1GXgfV04cWRY="; </ins> nativeBuildInputs = [ cmake
Code change:
Updated using I though most of the packages have moved on to openblas, what is pulling in this package? How would I find out?
A few packages still reference it. should show what derivations use it directly, from those you have instantiated.

Related discussion:
text: {stdenv, fetchurl}: stdenv.mkDerivation rec { <del> name = "ncompress-4.2.4.3"; </del> <ins> name = "ncompress-4.2.4.4"; </ins> builder = ./builder.sh;
Code change:
Updated using I though most of the packages have moved on to openblas, what is pulling in this package? How would I find out?
A few packages still reference it. should show what derivations use it directly, from those you have instantiated.

Related discussion:
text: src = fetchurl { url = "mirror://sourceforge/project/ncompress/${name}.tar.gz"; <del> sha256 = "1y44ixc1w2vfvj1lm4dkcljlwv882ynrvm5i6l0lg1gf883j246l"; </del> <ins> sha256 = "0yjiwv1hwb253x3m6r1dq2k7m5c9nz0ib2j7fnm3hark7y6s42xh"; </ins> }; meta = {
Code change:
Describe the bug option is not working To Reproduce Steps to reproduce the behavior: service and its option in . Add as well for testing. In my case I used something similar to the password read bit is set, for the test generation: (eventually) inspect logs with in a separate terminal a mail The command might return And you might find an error similar to this in your logs Tested on 19.09 and 20.09, on different machines with three different SMTP hosts, various passwords, with and without special characters. As explicitly warn in the doc Path to a file that contains the password used for SMTP auth. The file should not contain a trailing newline, if the password does not contain one. This file should be readable by the users that need to execute ssmtp. I ensured that the password do not contains a leading space or carriage return. Expected behavior should work just as well as its former obsolete attribute. Additional context eventually check again my password in the store: which is yet followed by the character . It's obviously a control character and I cannot find a definition of its meaning. The very same command (original pass file) won't return the . following configuration works, with of course the exact same password as provided in the password file. Which is obviously not the expected setup. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Make sure that it doesn't have a trailing either. Editors like vim tend to insert one by default.
I can confirm.
Is this still a problem?
I haven't been able to validate the response using or alternative editors.
Use to avoid the trailing newline. To check whether there's one, use ; with this command, newlines are displayed as .

Related discussion:
text: example = "/run/keys/ssmtp-authpass"; description = '' Path to a file that contains the password used for SMTP auth. The file <del> should not contain a trailing newline, if the password does not contain one. </del> <ins> should not contain a trailing newline, if the password does not contain one (e.g. use <command>echo -n "password" > file</command>). </ins> This file should be readable by the users that need to execute ssmtp. ''; };
Code change:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)

Related discussion:
text: <para> This chapter describes tools for creating various types of images. </para> <del> <xi:include href="images/appimagetools.xml" /> </del> <ins> <xi:include href="images/appimagetools.section.xml" /> </ins> <xi:include href="images/dockertools.section.xml" /> <xi:include href="images/ocitools.section.xml" /> <del> <xi:include href="images/snaptools.xml" /> </del> <ins> <xi:include href="images/snaptools.section.xml" /> </ins> </chapter>
Code change:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)

Related discussion:
text: <del> let inherit (import <nixpkgs> { }) snapTools firefox; in snapTools.makeSnap { meta = { name = "nix-example-firefox"; summary = firefox.meta.description; architectures = [ "amd64" ]; apps.nix-example-firefox = { command = "${firefox}/bin/firefox"; plugs = [ "pulseaudio" "camera" "browser-support" "avahi-observe" "cups-control" "desktop" "desktop-legacy" "gsettings" "home" "network" "mount-observe" "removable-media" "x11" ]; }; confinement = "strict"; }; } </del>
Code change:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)

Related discussion:
text: <del> let inherit (import <nixpkgs> { }) snapTools hello; in snapTools.makeSnap { meta = { name = "hello"; summary = hello.meta.description; description = hello.meta.longDescription; architectures = [ "amd64" ]; confinement = "strict"; apps.hello.command = "${hello}/bin/hello"; }; } </del>
Code change:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)

Related discussion:
text: <ins> # pkgs.snapTools {#sec-pkgs-snapTools} `pkgs.snapTools` is a set of functions for creating Snapcraft images. Snap and Snapcraft is not used to perform these operations. ## The makeSnap Function {#ssec-pkgs-snapTools-makeSnap-signature} `makeSnap` takes a single named argument, `meta`. This argument mirrors [the upstream `snap.yaml` format](https://docs.snapcraft.io/snap-format) exactly. The `base` should not be specified, as `makeSnap` will force set it. Currently, `makeSnap` does not support creating GUI stubs. ## Build a Hello World Snap {#ssec-pkgs-snapTools-build-a-snap-hello} The following expression packages GNU Hello as a Snapcraft snap. ```{#ex-snapTools-buildSnap-hello .nix} let inherit (import <nixpkgs> { }) snapTools hello; in snapTools.makeSnap { meta = { name = "hello"; summary = hello.meta.description; description = hello.meta.longDescription; architectures = [ "amd64" ]; confinement = "strict"; apps.hello.command = "${hello}/bin/hello"; }; } ``` `nix-build` this expression and install it with `snap install ./result --dangerous`. `hello` will now be the Snapcraft version of the package. ## Build a Graphical Snap {#ssec-pkgs-snapTools-build-a-snap-firefox} Graphical programs require many more integrations with the host. This example uses Firefox as an example, because it is one of the most complicated programs we could package. ```{#ex-snapTools-buildSnap-firefox .nix} let inherit (import <nixpkgs> { }) snapTools firefox; in snapTools.makeSnap { meta = { name = "nix-example-firefox"; summary = firefox.meta.description; architectures = [ "amd64" ]; apps.nix-example-firefox = { command = "${firefox}/bin/firefox"; plugs = [ "pulseaudio" "camera" "browser-support" "avahi-observe" "cups-control" "desktop" "desktop-legacy" "gsettings" "home" "network" "mount-observe" "removable-media" "x11" ]; }; confinement = "strict"; }; } ``` `nix-build` this expression and install it with `snap install ./result --dangerous`. `nix-example-firefox` will now be the Snapcraft version of the Firefox package. The specific meaning behind plugs can be looked up in the [Snapcraft interface documentation](https://docs.snapcraft.io/supported-interfaces). </ins>
Code change:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)

Related discussion:
text: <del> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xi="http://www.w3.org/2001/XInclude" xml:id="sec-pkgs-snapTools"> <title>pkgs.snapTools</title> <para> <varname>pkgs.snapTools</varname> is a set of functions for creating Snapcraft images. Snap and Snapcraft is not used to perform these operations. </para> <section xml:id="ssec-pkgs-snapTools-makeSnap-signature"> <title>The makeSnap Function</title> <para> <function>makeSnap</function> takes a single named argument, <parameter>meta</parameter>. This argument mirrors <link xlink:href="https://docs.snapcraft.io/snap-format">the upstream <filename>snap.yaml</filename> format</link> exactly. </para> <para> The <parameter>base</parameter> should not be specified, as <function>makeSnap</function> will force set it. </para> <para> Currently, <function>makeSnap</function> does not support creating GUI stubs. </para> </section> <section xml:id="ssec-pkgs-snapTools-build-a-snap-hello"> <title>Build a Hello World Snap</title> <example xml:id="ex-snapTools-buildSnap-hello"> <title>Making a Hello World Snap</title> <para> The following expression packages GNU Hello as a Snapcraft snap. </para> <programlisting><xi:include href="./snap/example-hello.nix" parse="text" /></programlisting> <para> <command>nix-build</command> this expression and install it with <command>snap install ./result --dangerous</command>. <command>hello</command> will now be the Snapcraft version of the package. </para> </example> </section> <section xml:id="ssec-pkgs-snapTools-build-a-snap-firefox"> <title>Build a Hello World Snap</title> <example xml:id="ex-snapTools-buildSnap-firefox"> <title>Making a Graphical Snap</title> <para> Graphical programs require many more integrations with the host. This example uses Firefox as an example, because it is one of the most complicated programs we could package. </para> <programlisting><xi:include href="./snap/example-firefox.nix" parse="text" /></programlisting> <para> <command>nix-build</command> this expression and install it with <command>snap install ./result --dangerous</command>. <command>nix-example-firefox</command> will now be the Snapcraft version of the Firefox package. </para> <para> The specific meaning behind plugs can be looked up in the <link xlink:href="https://docs.snapcraft.io/supported-interfaces">Snapcraft interface documentation</link>. </para> </example> </section> </section> </del>
Code change:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.

Related discussion:
text: <para> This chapter describes tools for creating various types of images. </para> <del> <xi:include href="images/appimagetools.xml" /> </del> <ins> <xi:include href="images/appimagetools.section.xml" /> </ins> <xi:include href="images/dockertools.section.xml" /> <xi:include href="images/ocitools.section.xml" /> <del> <xi:include href="images/snaptools.xml" /> </del> <ins> <xi:include href="images/snaptools.section.xml" /> </ins> </chapter>