jiebi/CodeConvo huggingface dataset:
Code change:
When I trying to install twinkle, I recieve such error:
I tried to fix twinkle a few weeks ago, and I did get it further, but I didn't fix it completely. I can try to find the WIP this evening if someone is interested.
I managed to fix it in the end. Details are in the commit message.

Related discussion:
text: src = fetchurl { url = "mirror://kernel/linux/kernel/v3.x/${if testing then "testing/" else ""}linux-${version}.tar.xz"; <del> sha256 = "0pd96g1qcp2wgdnvk79hljjrpr6xjk0159lks47n181a3yirzf4x"; </del> <ins> sha256 = "0l4h7amhsmgpnii8rgwi32nd7ajsifk2xckjd39pfzwdifacw5yw"; </ins> }; config = configWithPlatform stdenv.platform;
Code change:
Currently, the retpoline mitigation is only available in gcc7 . However, it still exists some old kernels that only compile with , such as those in Ubuntu Trusty LTS (kernel 3.13). Moreover, kernel modules loaded on these kernel have also to be compiled with the retpoline mitigation. Ubuntu (and Debian) integrated retpoline mitigation in their releases . Latest Ubuntu 3.13 kernel now requires kernel modules compiled with retpoline mitigation. They can no longer be built with Nix gcc toolchain. What do you think about backporting these patches? Someone could help on this?
sounds good to me.

Related discussion:
text: <del> { stdenv, targetPackages, fetchurl, noSysDirs </del> <ins> { stdenv, targetPackages, fetchurl, noSysDirs, fetchpatch </ins> , langC ? true, langCC ? true, langFortran ? false , langObjC ? targetPlatform.isDarwin , langObjCpp ? targetPlatform.isDarwin
Code change:
Currently, the retpoline mitigation is only available in gcc7 . However, it still exists some old kernels that only compile with , such as those in Ubuntu Trusty LTS (kernel 3.13). Moreover, kernel modules loaded on these kernel have also to be compiled with the retpoline mitigation. Ubuntu (and Debian) integrated retpoline mitigation in their releases . Latest Ubuntu 3.13 kernel now requires kernel modules compiled with retpoline mitigation. They can no longer be built with Nix gcc toolchain. What do you think about backporting these patches? Someone could help on this?
sounds good to me.

Related discussion:
text: ++ optional noSysDirs ../no-sys-dirs.patch ++ optional langFortran ../gfortran-driving.patch ++ [ ../struct-ucontext.patch ../struct-sigaltstack-4.9.patch ] # glibc-2.26 <del> ; </del> <ins> # Retpoline patches pulled from the branch hjl/indirect/gcc-4_9-branch (by H.J. Lu, the author of GCC upstream retpoline commits) ++ builtins.map ({commit, sha256}: fetchpatch {url = "https://github.com/hjl-tools/gcc/commit/${commit}.patch"; inherit sha256;}) [{ commit = "e623d21608e96ecd6b65f0d06312117d20488a38"; sha256 = "1ix8i4d2r3ygbv7npmsdj790rhxqrnfwcqzv48b090r9c3ij8ay3"; } { commit = "2015a09e332309f12de1dadfe179afa6a29368b8"; sha256 = "0xcfs0cbb63llj2gbcdrvxim79ax4k4aswn0a3yjavxsj71s1n91"; } { commit = "6b11591f4494f705e8746e7d58b7f423191f4e92"; sha256 = "0aydyhsm2ig0khgbp27am7vq7liyqrq6kfhfi2ki0ij0ab1hfbga"; } { commit = "203c7d9c3e9cb0f88816b481ef8e7e87b3ecc373"; sha256 = "0wqn16y7wy5kg8ngfcni5qdwfphl01axczibbk49bxclwnzvldqa"; } { commit = "f039c6f284b2c9ce97c8353d6034978795c4872e"; sha256 = "13fkgdb17lpyxfksz1zanxhgpsm0jrss9w61nbl7an4im22hz7ci"; } { commit = "ed42606bdab1c5d9e5ad828cd6fe1a0557f193b7"; sha256 = "0gdnn8v3p03imj3qga2mzdhpgbmjcklkxdl97jvz5xia2ikzknxm"; } { commit = "5278e062ef292fd2fbf987d25389785f4c5c0f99"; sha256 = "0j81x758wf8v7j4rx5wc1cy7yhkvhlhv3wmnarwakxiwsspq0vrs"; } { commit = "76f1ffbbb6cd9f6ecde6c82cd16e20a27242e890"; sha256 = "1py56y6gp7fjf4f8bbsfwh5bs1gnmlqda1ycsmnwlzfm0cshdp0c"; } { commit = "4ca48b2b688b135c0390f54ea9077ef10aedd52c"; sha256 = "15r019pzr3k0lpgyvdc92c8fayw8b5lrzncna4bqmamcsdz7vsaw"; } { commit = "98c7bf9ddc80db965d69d61521b1c7a1cec32d9a"; sha256 = "1d7pfdv1q23nf0wadw7jbp6d6r7pnzjpbyxgbdfv7j1vr9l1bp60"; } { commit = "3dc76b53ad896494ca62550a7a752fecbca3f7a2"; sha256 = "0jvdzfpvfdmklfcjwqblwq1i22iqis7ljpvm7adra5d7zf2xk7xz"; } { commit = "1e961ed49b18e176c7457f53df2433421387c23b"; sha256 = "04dnqqs4qsvz4g8cq6db5id41kzys7hzhcaycwmc9rpqygs2ajwz"; } { commit = "e137c72d099f9b3b47f4cc718aa11eab14df1a9c"; sha256 = "1ms0dmz74yf6kwgjfs4d2fhj8y6mcp2n184r3jk44wx2xc24vgb2"; }]; </ins> javaEcj = fetchurl { # The `$(top_srcdir)/ecj.jar' file is automatically picked up at
Code change:
Currently, the retpoline mitigation is only available in gcc7 . However, it still exists some old kernels that only compile with , such as those in Ubuntu Trusty LTS (kernel 3.13). Moreover, kernel modules loaded on these kernel have also to be compiled with the retpoline mitigation. Ubuntu (and Debian) integrated retpoline mitigation in their releases . Latest Ubuntu 3.13 kernel now requires kernel modules compiled with retpoline mitigation. They can no longer be built with Nix gcc toolchain. What do you think about backporting these patches? Someone could help on this?
sounds good to me.

Related discussion:
text: platforms = stdenv.lib.platforms.linux ++ stdenv.lib.platforms.freebsd ++ <del> stdenv.lib.platforms.illumos ++ stdenv.lib.platforms.darwin; </del> <ins> stdenv.lib.platforms.illumos; </ins> }; }
Code change:
When saving a plot figure to pdf in Octave, the program panics and aborts Reproducible with both and from . If the GUI is used, the program exits with signal 6.
Does suffer from the same problem?
Yes, same problem with .
Requires in , which we have not packaged yet.
this should be reopened, octave lacks in so the issue still stands. I think should be included in both and . Mainly so command line users can still save graphs to a file. I can make the necessary changes eventually or if someone else wants to that would be nice.
Oops sorry

Related discussion:
text: github = "twey"; name = "James ‘Twey’ Kay"; }; <ins> twhitehead = { name = "Tyson Whitehead"; email = "twhitehead@gmail.com"; github = "twhitehead"; keys = [{ longkeyid = "rsa2048/0x594258F0389D2802"; fingerprint = "E631 8869 586F 99B4 F6E6  D785 5942 58F0 389D 2802"; }]; }; </ins> typetetris = { email = "ericwolf42@mail.com"; github = "typetetris";
Code change:
When saving a plot figure to pdf in Octave, the program panics and aborts Reproducible with both and from . If the GUI is used, the program exits with signal 6.
Does suffer from the same problem?
Yes, same problem with .
Requires in , which we have not packaged yet.
this should be reopened, octave lacks in so the issue still stands. I think should be included in both and . Mainly so command line users can still save graphs to a file. I can make the necessary changes eventually or if someone else wants to that would be nice.
Oops sorry

Related discussion:
text: <ins> { stdenv, fetchurl, cmake , zlib, libGL, libGLU, libpng, freeglut }: stdenv.mkDerivation rec { version = "1.4.0"; name = "gl2ps-${version}"; src = fetchurl { url = "http://geuz.org/gl2ps/src/${name}.tgz"; sha256 = "1qpidkz8x3bxqf69hlhyz1m0jmfi9kq24fxsp7rq6wfqzinmxjq3"; }; buildInputs = [ cmake zlib libGL libGLU libpng freeglut ]; meta = with stdenv.lib; { homepage = http://geuz.org/gl2ps; description = "An OpenGL to PostScript printing library"; platforms = platforms.all; license = licenses.lgpl2; maintainers = with maintainers; [raskin twhitehead]; }; } </ins>
Code change:
When saving a plot figure to pdf in Octave, the program panics and aborts Reproducible with both and from . If the GUI is used, the program exits with signal 6.
Does suffer from the same problem?
Yes, same problem with .
Requires in , which we have not packaged yet.
this should be reopened, octave lacks in so the issue still stands. I think should be included in both and . Mainly so command line users can still save graphs to a file. I can make the necessary changes eventually or if someone else wants to that would be nice.
Oops sorry

Related discussion:
text: gitea = callPackage ../applications/version-management/gitea { }; <ins> gl2ps = callPackage ../development/libraries/gl2ps { }; </ins> glusterfs = callPackage ../tools/filesystems/glusterfs { }; glmark2 = callPackage ../tools/graphics/glmark2 { };
Code change:
The MTU of the ethernet should be set to 1460 on google cloud platform, but it is set to 1500. For me this has occasionally, but not always caused the ssh terminal to hang when lots of data is being printed, and I assume could be causing other people issues. from - Create a google compute engine nixos image from observe the mtu on eth0 is 1500. Set the following: to fix the issue. system: host os: multi-user?: sandbox: version: nixpkgs:
I created based on what you wrote but didn't test it.
Thanks, that fix was enough for me, though I don't know if it works in all situations, or if DHCP is not picking up some parameter like it is supposed to. I don't really know how to proceed with a fix for sure, but I thought I would document the issue.

Related discussion:
text: networking.usePredictableInterfaceNames = false; <ins> # GC has 1460 MTU networking.interfaces.eth0.mtu = 1460; </ins> # allow the google-accounts-daemon to manage users users.mutableUsers = true; # and allow users to sudo without password
Code change:
The bullet points under Chapter 2, section 8 (the fdisk process) don't match up with what the real partitions are after write. The last four lines of fdisk setup are relevant: Earlier in the fdisk process, we create the partitions with the following numbering: I believe the re-numbers the partitions based on their location within the partition label. Since the boot partition is at the front of the disk and our partition is at the end, fdisk reorders the partitions as follows: The problem is when making the file systems. The manual still uses the initial partition numbers instead of the new, ordered numbers. Thus: Creates an ext4 partition that is 512M big and is supposed to be boot. And: Creates a FAT32 partiton that's supposed to be our root labeled . Swap isn't affected being in the middle.
Hi! Closing this issue since the partitioning instructions are now re-written for 18.09. (See ) As far as the ordering of partitions is concerned, the newly re-written partitioning instructions were written to ensure it wouldn't be an issue.

Related discussion:
text: .PHONY: debug debug: generated manual-combined.xml <del> manual-combined.xml: generated *.xml </del> <ins> manual-combined.xml: generated *.xml **/*.xml </ins> rm -f ./manual-combined.xml nix-shell --packages xmloscopy  --run "xmloscopy --docbook5 ./manual.xml ./manual-combined.xml"
Code change:
The bullet points under Chapter 2, section 8 (the fdisk process) don't match up with what the real partitions are after write. The last four lines of fdisk setup are relevant: Earlier in the fdisk process, we create the partitions with the following numbering: I believe the re-numbers the partitions based on their location within the partition label. Since the boot partition is at the front of the disk and our partition is at the end, fdisk reorders the partitions as follows: The problem is when making the file systems. The manual still uses the initial partition numbers instead of the new, ordered numbers. Thus: Creates an ext4 partition that is 512M big and is supposed to be boot. And: Creates a FAT32 partiton that's supposed to be our root labeled . Swap isn't affected being in the middle.
Hi! Closing this issue since the partitioning instructions are now re-written for 18.09. (See ) As far as the ordering of partitions is concerned, the newly re-written partitioning instructions were written to ensure it wouldn't be an issue.

Related discussion:
text: For systems without CD drive, the NixOS live CD can be booted from a USB stick. You can use the <command>dd</command> utility to write the image: <command>dd if=<replaceable>path-to-image</replaceable> <del> of=<replaceable>/dev/sdb</replaceable></command>. Be careful about specifying </del> <ins> of=<replaceable>/dev/sdX</replaceable></command>. Be careful about specifying </ins> the correct drive; you can use the <command>lsblk</command> command to get a list of block devices. <del> </para> <para> On macOS: </del> <ins> <note> <title>On macOS</title> <para> </ins> <programlisting> $ diskutil list [..]
Code change:
The bullet points under Chapter 2, section 8 (the fdisk process) don't match up with what the real partitions are after write. The last four lines of fdisk setup are relevant: Earlier in the fdisk process, we create the partitions with the following numbering: I believe the re-numbers the partitions based on their location within the partition label. Since the boot partition is at the front of the disk and our partition is at the end, fdisk reorders the partitions as follows: The problem is when making the file systems. The manual still uses the initial partition numbers instead of the new, ordered numbers. Thus: Creates an ext4 partition that is 512M big and is supposed to be boot. And: Creates a FAT32 partiton that's supposed to be our root labeled . Swap isn't affected being in the middle.
Hi! Closing this issue since the partitioning instructions are now re-written for 18.09. (See ) As far as the ordering of partitions is concerned, the newly re-written partitioning instructions were written to ensure it wouldn't be an issue.

Related discussion:
text: Unmount of all volumes on diskN was successful $ sudo dd bs=1m if=nix.iso of=/dev/rdiskN </programlisting> <del> Using the 'raw' <command>rdiskN</command> device instead of <command>diskN</command> completes in minutes instead of hours. After <command>dd</command> completes, a GUI dialog "The disk you inserted was not readable by this computer" will pop up, which can be ignored. </del> <ins> Using the 'raw' <command>rdiskN</command> device instead of <command>diskN</command> completes in minutes instead of hours. After <command>dd</command> completes, a GUI dialog "The disk you inserted was not readable by this computer" will pop up, which can be ignored. </para> </note> </ins> </para> <para> The <command>dd</command> utility will write the image verbatim to the drive, making it the recommended option for both UEFI and non-UEFI installations. <del> For non-UEFI installations, you can alternatively use <link xlink:href="http://unetbootin.sourceforge.net/">unetbootin</link>. If you cannot use <command>dd</command> for a UEFI installation, you can also mount the ISO, copy its contents verbatim to your drive, then either: <itemizedlist> <listitem> <para> Change the label of the disk partition to the label of the ISO (visible with the blkid command), or </para> </listitem> <listitem> <para> Edit <filename>loader/entries/nixos-livecd.conf</filename> on the drive and change the <literal>root=</literal> field in the <literal>options</literal> line to point to your drive (see the documentation on <literal>root=</literal> in <link xlink:href="https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt"> the kernel documentation</link> for more details). </para> </listitem> <listitem> <para> If you want to load the contents of the ISO to ram after bootin (So you can remove the stick after bootup) you can append the parameter <literal>copytoram</literal> to the <literal>options</literal> field. </para> </listitem> </itemizedlist> </del> </para> </section>
Code change:
The bullet points under Chapter 2, section 8 (the fdisk process) don't match up with what the real partitions are after write. The last four lines of fdisk setup are relevant: Earlier in the fdisk process, we create the partitions with the following numbering: I believe the re-numbers the partitions based on their location within the partition label. Since the boot partition is at the front of the disk and our partition is at the end, fdisk reorders the partitions as follows: The problem is when making the file systems. The manual still uses the initial partition numbers instead of the new, ordered numbers. Thus: Creates an ext4 partition that is 512M big and is supposed to be boot. And: Creates a FAT32 partiton that's supposed to be our root labeled . Swap isn't affected being in the middle.
Hi! Closing this issue since the partitioning instructions are now re-written for 18.09. (See ) As far as the ordering of partitions is concerned, the newly re-written partitioning instructions were written to ensure it wouldn't be an issue.

Related discussion:
text: # nano /mnt/etc/nixos/configuration.nix # nixos-install # reboot</screen> <del> </example> <example xml:id='ex-config'> <title>NixOS Configuration</title> </del> <ins> </para> </example> <example xml:id='ex-config'> <title>NixOS Configuration</title> </ins> <screen> { config, pkgs, ... }: { imports = [
Code change:
The bullet points under Chapter 2, section 8 (the fdisk process) don't match up with what the real partitions are after write. The last four lines of fdisk setup are relevant: Earlier in the fdisk process, we create the partitions with the following numbering: I believe the re-numbers the partitions based on their location within the partition label. Since the boot partition is at the front of the disk and our partition is at the end, fdisk reorders the partitions as follows: The problem is when making the file systems. The manual still uses the initial partition numbers instead of the new, ordered numbers. Thus: Creates an ext4 partition that is 512M big and is supposed to be boot. And: Creates a FAT32 partiton that's supposed to be our root labeled . Swap isn't affected being in the middle.
Hi! Closing this issue since the partitioning instructions are now re-written for 18.09. (See ) As far as the ordering of partitions is concerned, the newly re-written partitioning instructions were written to ensure it wouldn't be an issue.

Related discussion:
text: services.sshd.enable = true; } </screen> <del> </example> <xi:include href="installing-usb.xml" /> <xi:include href="installing-pxe.xml" /> <xi:include href="installing-virtualbox-guest.xml" /> <xi:include href="installing-from-other-distro.xml" /> <xi:include href="installing-behind-a-proxy.xml" /> </del> <ins> </example> </section> <section xml:id="sec-installation-additional-notes"> <title>Additional installation notes</title> <xi:include href="installing-usb.xml" /> <xi:include href="installing-pxe.xml" /> <xi:include href="installing-virtualbox-guest.xml" /> <xi:include href="installing-from-other-distro.xml" /> <xi:include href="installing-behind-a-proxy.xml" /> </section> </ins> </chapter>
Code change:
has been broken on master for a while now, blocking orca. I opened an but they are not sure how to fix it.
I removed it from orca in

Related discussion:
text: , python, pygobject3, gtk3, gnome3, substituteAll , at-spi2-atk, at-spi2-core, pyatspi, dbus, dbus-python, pyxdg , xkbcomp, procps, lsof, coreutils, gsettings-desktop-schemas <del> , speechd, brltty, setproctitle, gst_all_1, gst-python </del> <ins> , speechd, brltty, liblouis, setproctitle, gst_all_1, gst-python </ins> }: buildPythonApplication rec {
Code change:
has been broken on master for a while now, blocking orca. I opened an but they are not sure how to fix it.
I removed it from orca in

Related discussion:
text: ]; propagatedBuildInputs = [ <del> # TODO: re-add liblouis when it is fixed pygobject3 pyatspi dbus-python pyxdg brltty speechd gst-python setproctitle </del> <ins> pygobject3 pyatspi dbus-python pyxdg brltty liblouis speechd gst-python setproctitle </ins> ]; <ins> strictDeps = false; </ins> buildInputs = [ python gtk3 at-spi2-atk at-spi2-core dbus gsettings-desktop-schemas gst_all_1.gstreamer gst_all_1.gst-plugins-base gst_all_1.gst-plugins-good
Code change:
Tried to make a system upgrade, got this: Obviously, upgrade can't be completed. have in . run Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
This looks like the offending line: This could be related to what file system you are using?
Actually this looks like unrelated to glslang. Works on master:

Related discussion:
text: <del> { stdenv, fetchFromGitHub, cmake, bison }: </del> <ins> { stdenv, fetchFromGitHub, cmake, bison, spirv-tools, jq }: </ins> stdenv.mkDerivation rec { name = "glslang-git-${version}"; <del> version = "2017-08-31"; </del> <ins> version = "2018-02-05"; </ins> # `vulkan-loader` requires a specific version of `glslang` as specified in # `<vulkan-loader-repo>/external_revisions/glslang_revision`. src = fetchFromGitHub { owner = "KhronosGroup"; repo = "glslang"; <del> rev = "3a21c880500eac21cdf79bef5b80f970a55ac6af"; sha256 = "1i15m17r0acmzjrkybris2rgw15il05a4w5h7vhhsiyngcvajcyn"; </del> <ins> rev = "2651ccaec8"; sha256 = "0x5x5i07n9g809rzf5jgw70mmwck31ishdmxnmi0wxx737jjqwaq"; </ins> }; <del> buildInputs = [ cmake bison ]; </del> <ins> buildInputs = [ cmake bison jq ] ++ spirv-tools.buildInputs; </ins> enableParallelBuilding = true; <ins> patchPhase = '' cp --no-preserve=mode -r "${spirv-tools.src}" External/spirv-tools ln -s "${spirv-tools.headers}" External/spirv-tools/external/spirv-headers ''; preConfigure = '' HEADERS_COMMIT=$(jq -r < known_good.json '.commits|map(select(.name=="spirv-tools/external/spirv-headers"))[0].commit') TOOLS_COMMIT=$(jq -r < known_good.json '.commits|map(select(.name=="spirv-tools"))[0].commit') if [ "$HEADERS_COMMIT" != "${spirv-tools.headers.rev}" ] || [ "$TOOLS_COMMIT" != "${spirv-tools.src.rev}" ]; then echo "ERROR: spirv-tools commits do not match expected versions"; exit 1; fi ''; </ins> meta = with stdenv.lib; { inherit (src.meta) homepage; description = "Khronos reference front-end for GLSL and ESSL";
Code change:
Tried to make a system upgrade, got this: Obviously, upgrade can't be completed. have in . run Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
This looks like the offending line: This could be related to what file system you are using?
Actually this looks like unrelated to glslang. Works on master:

Related discussion:
text: libXext, wayland, libGL, makeWrapper }: let <del> version = "1.0.61.1"; </del> <ins> version = "1.1.70.0"; </ins> src = fetchFromGitHub { owner = "KhronosGroup"; repo = "Vulkan-LoaderAndValidationLayers"; rev = "sdk-${version}"; <del> sha256 = "043kw6wnrpdplnb40x6n9rgf3gygsn9jiv91y458sydbhalfr945"; </del> <ins> sha256 = "1a7xwl65bi03l4zbjq54qkxjb8kb4m78qvw8bas5alhf9v6i6yqp"; </ins> }; in
Code change:
Tried to make a system upgrade, got this: Obviously, upgrade can't be completed. have in . run Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
This looks like the offending line: This could be related to what file system you are using?
Actually this looks like unrelated to glslang. Works on master:

Related discussion:
text: nativeBuildInputs = [ makeWrapper pkgconfig ]; buildInputs = [ cmake git python3 python3Packages.lxml <del> glslang spirv-tools x11 libxcb libXrandr libXext wayland </del> <ins> glslang x11 libxcb libXrandr libXext wayland </ins> ]; enableParallelBuilding = true;
Code change:
Tried to make a system upgrade, got this: Obviously, upgrade can't be completed. have in . run Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
This looks like the offending line: This could be related to what file system you are using?
Actually this looks like unrelated to glslang. Works on master:

Related discussion:
text: ]; outputs = [ "out" "dev" "demos" ]; <ins> patches = [ ./rev-file.patch ]; postUnpack = '' # Hack so a version header can be generated. Relies on ./rev-file.patch to work. mkdir -p "$sourceRoot/external/glslang/External" echo "${spirv-tools.src.rev}" > "$sourceRoot/external/glslang/External/spirv-tools" ''; </ins> preConfigure = '' checkRev() { [ "$2" = $(cat "external_revisions/$1_revision") ] || (echo "ERROR: dependency $1 is revision $2 but should be revision" $(cat "external_revisions/$1_revision") && exit 1) } <del> checkRev spirv-tools "${spirv-tools.src.rev}" checkRev spirv-headers "${spirv-tools.headers.rev}" </del> checkRev glslang "${glslang.src.rev}" '';