jiebi/CodeConvo huggingface dataset:
Change:
containers started with (or related options) only see a loopback interface, the desired interface to the host is missing. Same applies to containers created by . Problem exists with linux 4.14 and systemd 238. With linux 4.9 and systemd 238, container networking looks ok. See also discussion in /cc Any of these: fails, container complains about missing interface Try to start a container created by . manual tests with show only loopback interface in container. 03pre131587..
For reference, the current 18.03 branch downgraded systemd to 237 (mainly due to this), but the big 18.03 channel is still with systemd-238 ATM.
One thing I observed is that we compile systemd (and glibc etc. ) with the latest linux-headers (currently 4.15), no matter what kernel version actually runs on the system. This may not work according to : means that a program built against a C library using older kernel headers should run on a newer kernel (although it may not have access to new features), but a program built against newer kernel headers may not work on an older kernel_. Don't know if that is relevant for this issue but will do a little experiment.
Oh, from discussion here I understood otherwise, which is why it was deemed safe to bump the headers. /cc IIRC.
After rebuilding with kernel headers downgraded to 4.14, the issue is still there - so that's not the cause.
We pass to glibc... I wouldn't be completely surprised if things still break with that, but it's not expected at least :grinning:
I can confirm it on Arch Linux - this bug is same with kernel 4.14 and systemd 238. With kernel 4.15 all works normaly.
Thank you I will open an upstream systemd issue for this.
Opened
There's a proposed fix in systemd/systemd (not yet merged). I just tested it on NixOS - seems to fix this issue. Will make a PR for nixos/systemd when the fix is merged upstream.
fixed in

Discussion:
version = "238"; name = "systemd-${version}"; <ins> # When updating, use https://github.com/systemd/systemd-stable tree, not the development one! # Also fresh patches should be cherry-picked from that tree to our current one. </ins> src = fetchFromGitHub { owner = "NixOS"; repo = "systemd"; <del> rev = "243d65d38f2df82d4a39f6a9970337803dff65a1"; sha256 = "098hxlkh6q17rxa178adylksxnnd4x9rxb8amjnlbiydcc6kaa5n"; </del> <ins> rev = "3a439bcdb5706dbb44215ef4e70f07b09aaac040"; sha256 = "0qkk5891068pkxmxqvm07bwl597i8lfp89c23yxp11m21cjq0f4b"; </ins> }; outputs = [ "out" "lib" "man" "dev" ];
Change:
Upstream bug: Random hydra log: We should probably switch back to autotools as suggested until it's fixed upstream? Or would turning parallel building off fix it too? cc
Sounds good to me.

Discussion:
, gnomeSupport ? false, gnome, makeWrapper , libimobiledevice, libbluray, libcdio-paranoia, libnfs, openssh , libsecret, libgdata <ins> # Remove when switching back to meson , autoreconfHook, lzma, bzip2 </ins> }: <ins> # TODO: switch to meson when upstream fixes a non-deterministic build failure # See https://bugzilla.gnome.org/show_bug.cgi?id=794549 # Meson specific things are commented out and annotated, so switching back # should simply require deleting autotools specific things and adding back meson # flags etc. </ins> let pname = "gvfs"; version = "1.36.0";

sha256 = "1fsn6aa9a68cfbna9s00l1ry4ym1fr7ii2f45hzj2fipxfpqihwy"; }; <del> postPatch = '' chmod +x meson_post_install.py # patchShebangs requires executable file patchShebangs meson_post_install.py ''; </del> <ins> # Uncomment when switching back to meson # postPatch = '' #   chmod +x meson_post_install.py # patchShebangs requires executable file #   patchShebangs meson_post_install.py # ''; </ins> nativeBuildInputs = [ <del> meson ninja </del> <ins> autoreconfHook # Remove when switching to meson # meson ninja </ins> pkgconfig gettext makeWrapper libxml2 libxslt docbook_xsl docbook_xml_dtd_42 ];

libgphoto2 avahi libarchive fuse libcdio samba libmtp libcap polkit libimobiledevice libbluray libcdio-paranoia libnfs openssh <ins> # Remove when switching back to meson lzma bzip2 </ins> # ToDo: a ligther version of libsoup to have FTP/HTTP support? ] ++ stdenv.lib.optionals gnomeSupport (with gnome; [ libsoup gcr gnome-online-accounts libsecret libgdata ]); <del> mesonFlags = [ "-Dgio_module_dir=lib/gio/modules" "-Dsystemduserunitdir=lib/systemd/user" "-Ddbus_service_dir=share/dbus-1/services" "-Dtmpfilesdir=no" ] ++ stdenv.lib.optionals (!gnomeSupport) [ "-Dgcr=false" "-Dgoa=false" "-Dkeyring=false" "-Dhttp=false" "-Dgoogle=false" ] ++ stdenv.lib.optionals (samba == null) [ # Xfce don't want samba "-Dsmb=false" ]; </del> <ins> # Remove when switching back to meson configureFlags = stdenv.lib.optional (!gnomeSupport) "--disable-gcr"; # Uncomment when switching back to meson # mesonFlags = [ #   "-Dgio_module_dir=lib/gio/modules" #   "-Dsystemduserunitdir=lib/systemd/user" #   "-Ddbus_service_dir=share/dbus-1/services" #   "-Dtmpfilesdir=no" # ] ++ stdenv.lib.optionals (!gnomeSupport) [ #   "-Dgcr=false" "-Dgoa=false" "-Dkeyring=false" "-Dhttp=false" #   "-Dgoogle=false" # ] ++ stdenv.lib.optionals (samba == null) [ #   # Xfce don't want samba #   "-Dsmb=false" # ]; </ins> enableParallelBuilding = true;
Change:
Unable to download the public google cloud image, Can confirm the other very outdated images are downloadable. The bucket object is not world readable.
Would really appreciate a fix to this, combined with I can't create a working vm. edit: worked around.
Having the same issue
Where did you get the link from? I think the URI should be: gs://nixos-cloud-images/nixos-image-18.03..-x86_64-
This page There is definitely a new image someone too. The bucket url you listed is not public either. To be honest, I didn't trust those images and built my own. I made this issue to benefit other people.
I have removed that image, as the nixos-images bucket is an old bucket. Probably got upload accidentally, when the creation script referred to it still. I tried generating a new image, however, that has issues connecting via ssh (nixops), as some code was removed from nixpkgs that downloads SSH host key from metadata in . I might have time to look into that next week. Not sure yet what the correct way forward is.
I'll have look at the issue in nixops this weekend.
Is there a new 18.03 image now ? I can't seem to find a link to it in the nixpkgs repo.
I think the issue preventing the image generation was fixed now. Otherwise, afaik takes care of updating the images, so better ask him if there is anything else pending ?
(25 days ago) mentions an image from May 29 currently being present, after these comments, but still quite old, and for 18.03, 18.09 is still missing. Closing this issue in favour of .

Discussion:
echo "Obtaining SSH keys..." mkdir -m 0700 -p /root/.ssh AUTH_KEYS=$(${mktemp}) <del> ${wget} -O $AUTH_KEYS --header="Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/attributes/sshKeys </del> <ins> ${wget} -O $AUTH_KEYS http://metadata.google.internal/computeMetadata/v1/instance/attributes/sshKeys </ins> if [ -s $AUTH_KEYS ]; then # Read in key one by one, split in case Google decided

false fi rm -f $AUTH_KEYS <ins> SSH_HOST_KEYS_DIR=$(${mktemp} -d) ${wget} -O $SSH_HOST_KEYS_DIR/ssh_host_ed25519_key http://metadata.google.internal/computeMetadata/v1/instance/attributes/ssh_host_ed25519_key ${wget} -O $SSH_HOST_KEYS_DIR/ssh_host_ed25519_key.pub http://metadata.google.internal/computeMetadata/v1/instance/attributes/ssh_host_ed25519_key_pub if [ -s $SSH_HOST_KEYS_DIR/ssh_host_ed25519_key -a -s $SSH_HOST_KEYS_DIR/ssh_host_ed25519_key.pub ]; then mv -f $SSH_HOST_KEYS_DIR/ssh_host_ed25519_key* /etc/ssh/ chmod 600 /etc/ssh/ssh_host_ed25519_key chmod 644 /etc/ssh/ssh_host_ed25519_key.pub else echo "Setup of ssh host keys from http://metadata.google.internal/computeMetadata/v1/instance/attributes/ failed." false fi rm -f $SSH_HOST_KEYS_DIR </ins> ''; serviceConfig.Type = "oneshot"; serviceConfig.RemainAfterExit = true;
Change:
1/ The manual contains this command but it should be as doesn't accept the -L flag and it will warn when using lowercase 2/ the manual recommands but this gives "unknown filesystem type LVM2_member` for lvm 3/ it says to mount a drive in /mnt/boot but the folder doesn't exist 4/ apparently nixos-generate-config doesn't setup the root filesystem with LLVM: "the fileSystems option does not specify your root file system" Other propositions: Add useOSProber in the nixos-generate-config I know nixos targets more advanced users but I guess this can still be improved
The LVM example is meant as an additional way to explore. Simply following the command in the order presented is not promising. I'd suggest to leave out the logical volume setup code. Users with LVM knowledge probably know how to operate and friends. For users without LVM knowledge this is probably misleading.
thanks for the fixes !

Discussion:
<varlistentry><term>UEFI systems</term> <listitem><para>For creating boot partitions: <command>mkfs.fat</command>.  Again it’s recommended to assign a <del> label to the boot partition: <option>-L </del> <ins> label to the boot partition: <option>-n </ins> <replaceable>label</replaceable></option>. For example: <screen> <del> # mkfs.fat -F 32 -L boot /dev/sda3</screen> </del> <ins> # mkfs.fat -F 32 -n boot /dev/sda3</screen> </ins> </para></listitem></varlistentry></variablelist></listitem> <listitem><para>For creating LVM volumes, the LVM commands, e.g., <del> <screen> # pvcreate /dev/sda1 /dev/sdb1 # vgcreate MyVolGroup /dev/sda1 /dev/sdb1 # lvcreate --size 2G --name bigdisk MyVolGroup # lvcreate --size 1G --name smalldisk MyVolGroup</screen> </para></listitem> </del> <ins> <command>pvcreate</command>, <command>vgcreate</command>, and <command>lvcreate</command>.</para></listitem> </ins> <listitem><para>For creating software RAID devices, use <command>mdadm</command>.</para></listitem>

<listitem><para>Mount the boot file system on <filename>/mnt/boot</filename>, e.g. <screen> <ins> # mkdir -p /mnt/boot </ins> # mount /dev/disk/by-label/boot /mnt/boot </screen>

# mkfs.ext4 -L nixos /dev/sda1 # mkswap -L swap /dev/sda2 # swapon /dev/sda2 <del> # mkfs.fat -F 32 -L boot /dev/sda3        # <lineannotation>(for UEFI systems only)</lineannotation> </del> <ins> # mkfs.fat -F 32 -n boot /dev/sda3        # <lineannotation>(for UEFI systems only)</lineannotation> </ins> # mount /dev/disk/by-label/nixos /mnt <ins> # mkdir -p /mnt/boot                      # <lineannotation>(for UEFI systems only)</lineannotation> </ins> # mount /dev/disk/by-label/boot /mnt/boot # <lineannotation>(for UEFI systems only)</lineannotation> # nixos-generate-config --root /mnt # nano /mnt/etc/nixos/configuration.nix
Change:
Container start fails with privateNetwork = true; Does start when sharing host network.
I cannot reproduce this on my system with same nixos revision and your container config from above. Container starts and networking looks fine. Does your system have any kind of special network setup?
Whole config below : Only things that look interesting to me are virtualbox and perhaps the rkt service.
Ok, found the cause, was the hardened profile. Perhaps bpf is needed for virtual ethernet, will investigate some more.
Thanks. I never tried containers with the hardened profile. Will look into it.
Don't understand why yet, but adding to the host config seems to fix it. Hardened profile sets this to by default. please check if this works for you.
confirmed after a reboot.
I think a better solution will be to have the container module load all kernel modules required for private networking at boot time. Let's keep the issue open while I give that a try.
ping ;)
Module locking is quite heavy-handed. Loading all required modules before the lock is engaged is indeed the correct fix, if locking is desired.
Adding seems to fix the issue. I see that at least and is working, but am not sure about other things.
makes sense to me. If you care to, I'd be happy to integrate a PR to that effect.
Hello ! I stumbled upon this issue while trying to add a container with a private network, so I'm not sure this issue is resolved: I still had to add as suggested, which fixed the container startup.
Same here, still...

Discussion:
''; environment.systemPackages = [ pkgs.nixos-container ]; <ins> boot.kernelModules = [ "bridge" "macvlan" "tap" "tun" ]; </ins> }); }
Change:
in the result image has permissions . However the files inside have correct permissions. This makes impossible to use the store as a normal user. This is probably related to

Discussion:
# Record the contents of the tarball with ls_tar. ls_tar temp/layer.tar >> baseFiles <ins> # Append nix/store directory to the layer so that when the layer is loaded in the # image /nix/store has read permissions for non-root users. # nix/store is added only if the layer has /nix/store paths in it. if [ $(wc -l < $layerClosure) -gt 1 ] && [ $(grep -c -e "^/nix/store$" baseFiles) -eq 0 ]; then mkdir -p nix/store chmod -R 555 nix echo "./nix" >> layerFiles echo "./nix/store" >> layerFiles fi </ins> # Get the files in the new layer which were *not* present in # the old layer, and record them as newFiles. comm <(sort -n baseFiles|uniq)
Change:
system: host os: multi-user?: sandbox: version: channels(bjorn): channels(root): nixpkgs:

Discussion:
phantomjs = nodePackages.phantomjs.override (oldAttrs: { buildInputs = oldAttrs.buildInputs ++ [ pkgs.phantomjs2 ]; }); webdrvr = nodePackages.webdrvr.override (oldAttrs: { buildInputs = oldAttrs.buildInputs ++ [ pkgs.phantomjs ]; preRebuild = '' mkdir $TMPDIR/webdrvr ln -s ${pkgs.fetchurl { url = "https://selenium-release.storage.googleapis.com/2.43/selenium-server-standalone-2.43.1.jar"; sha1 = "ef1b5f8ae9c99332f99ba8794988a1d5b974d27b";

''; buildInputs = oldAttrs.buildInputs ++ [ pkgs.phantomjs2 ]; }); <ins> node2nix =  nodePackages.node2nix.override (oldAttrs: { buildInputs = oldAttrs.buildInputs ++ [ pkgs.makeWrapper ]; postInstall = '' wrapProgram "$out/bin/node2nix" --prefix PATH : ${stdenv.lib.makeBinPath [ pkgs.nix ]} ''; }); </ins> }
Change:
install supposed to complain abut missing files via : jdk-linux- , it fails silently: output:
By the looks of it, this is actually because it's unfree. See for how to get it working. Nevertheless, this should produce the same message as so it's still a bug.
you are right, but also produces not very meaningful message:
Indeed… With unfree packages allowed, should produce the right error message. So we've got several actual bugs here: doesn't exit with a nonzero error code, instead only failing to produce the outputs (making a PR for that just now) ignores evaluation errors even if no derivations are produced does not print the log for derivations with missing outputs (arguable)
nixos/nix

Discussion:
*** _EOF_ <ins> exit 1 </ins> ''; };
Change:
When using together with predictable interface names, there seems to be a race condition between activating the interfaces and renaming them, resulting in non-deterministic failure of interface renaming and setup. For an example, see these hydra builds: and Issue occurs on 18.03 and current master (i.e. with systemd 237 and 238). It is probably an upstream bug (but has not confirmed this yet). I found two similar reports: and Since the corresponding test is part of the jobs for the and channels, the sporadically failing test can delay the channels. I suggest removing this test from the jobs for the time being until this is fixed. Although the issue seems non-deterministic in nature (see hydra builds), I can quite reliably reproduce it running the test on my local machine: nixos or master
Note that our udev rules for network interfaces are not in sync with what systemd upstream uses. So that bugs in our system are probably different from what other linux distributions report.
The only relevant change to rules that I found so far is that we use a custom version of when predictable interface names are enabled. Not sure why the built-in upstream solution doesn't work for us.
After some tests, here's what I think is happening: Stage 1 discovers and adds the network interfaces with their original names. Renaming doesn't happen until stage 2. But tries to configure all interfaces it finds, so there's a race condition between stage 2 and . This can be (sort of) "solved" by an ugly hack: Add to to allow time for renaming. Fixes the test but slows down the boot and still does not guarantee success. A better solution might be to let stage 1 rename the interfaces. I tried but haven't quite figured out how to do this. We might try to go back to the upstream way of predictable interface names controlled by the kernel boot option. maybe you can help? (I found your from a long time ago, which was reverted after a few days)
Hmm not sure here, sorry!
Fixed by applying predictable interface names in stage 1 already.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Discussion:
systemd.services.systemd-networkd = { wantedBy = [ "multi-user.target" ]; restartTriggers = map (f: f.source) (unitFiles); <ins> # prevent race condition with interface renaming (#39069) requires = [ "systemd-udev-settle.service" ]; after = [ "systemd-udev-settle.service" ]; </ins> }; systemd.services.systemd-networkd-wait-online = {
Change:
As it stands, the package does not provide support for cloning filesystems; The symbolic links are missing. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:

Discussion:
{ stdenv, fetchFromGitHub, autoreconfHook <del> , pkgconfig, libuuid, e2fsprogs </del> <ins> , pkgconfig, libuuid, e2fsprogs, nilfs-utils, ntfs3g </ins> }: stdenv.mkDerivation rec {

nativeBuildInputs = [ autoreconfHook pkgconfig ]; buildInputs = [ <del> e2fsprogs libuuid stdenv.cc.libc </del> <ins> e2fsprogs libuuid stdenv.cc.libc nilfs-utils ntfs3g </ins> (stdenv.lib.getOutput "static" stdenv.cc.libc) ]; <ins> configureFlags = [ "--enable-xfs" "--enable-extfs" "--enable-hfsp" "--enable-fat" "--enable-exfat" "--enable-ntfs" "--enable-btrfs" "--enable-minix" "--enable-f2fs" "--enable-nilfs2" ]; </ins> enableParallelBuilding = true; meta = {
Change:
A goal of mine for 18.09 is to get rid of some legacy cross compilation stuff. We can now use "crossSystem" to accomplish the same thing. [x] pkgs/development/compilers/arm-frc-linux-gnueabi-gcc/ [ ] pkgs/development/misc/avr/ [ ] pkgs/development/compiler/gcc-arm-embedded/ [ ] pkgs/development/compilers/mentor/ We want to make sure we have easy alternatives for the above. This might include providing aliases if they are needed. Also we might want to have Hydra build toolchains for AVR and ARM embedded.
I another entry: pkgs/development/compilers/mentor/. (Currently holds two old ARM toolchains.)

Discussion:
{ stdenv, fetchurl, gmp, mpfr, libmpc, zlib, avrbinutils, texinfo }: let <del> version = "5.4.0"; </del> <ins> version = "7.3.0"; </ins> in stdenv.mkDerivation { name = "avr-gcc-${version}"; src = fetchurl { <del> url = "mirror://gcc/releases/gcc-${version}/gcc-${version}.tar.bz2"; sha256 = "0fihlcy5hnksdxk0sn6bvgnyq8gfrgs8m794b1jxwd1dxinzg3b0"; </del> <ins> url = "mirror://gcc/releases/gcc-${version}/gcc-${version}.tar.xz"; sha256 = "0p71bij6bfhzyrs8676a8jmpjsfz392s2rg862sdnsk30jpacb43"; </ins> }; patches = [

description = "GNU Compiler Collection, version ${version} for AVR microcontrollers"; homepage = http://gcc.gnu.org; license = licenses.gpl3Plus; <del> platforms = platforms.linux; </del> <ins> platforms = with platforms; linux ++ darwin; </ins> maintainers = with maintainers; [ mguentner ]; }; }
Change:
After a today, asciidoctor fails to install: I am afraid I have not spent time debugging, but this seemed worth reporting since the installation process itself fails which seems like it might be an infrastructure issue rather than a bug in the package? Ubuntu 17.10: WARNING removes any other packages (just to show it happens regardless of other packages installed):

Discussion:
"asciidoctor-latex" "asciidoctor-pdf" "asciidoctor-safe" <del> "asciidoctor-mathematical" </del> ]; gemConfig = {
Change:
has a test failure and won't install.
That's a known upstream issue:
I guess you didn't initially try to build pytest-sugar but some other package. That one should build fine once is merged.
thanks for looking into this. :)

Discussion:
{ stdenv, fetchPypi, buildPythonPackage , more-itertools, six <del> , coverage, codecov, pytest, pytestcov, pytest-sugar, portend </del> <ins> , pytest, pytestcov, portend </ins> , backports_unittest-mock, setuptools_scm }: buildPythonPackage rec {

buildInputs = [ setuptools_scm ]; <del> checkInputs = [ coverage codecov pytest pytestcov pytest-sugar portend backports_unittest-mock  ]; </del> <ins> checkInputs = [ pytest pytestcov portend backports_unittest-mock ]; </ins> checkPhase = '' py.test cheroot

{ lib, buildPythonPackage, fetchPypi , cheroot, portend, routes, six , setuptools_scm <del> , backports_unittest-mock, codecov, coverage, objgraph, pathpy, pytest, pytest-sugar, pytestcov </del> <ins> , backports_unittest-mock, objgraph, pathpy, pytest, pytestcov </ins> }: buildPythonPackage rec { <del> name = "${pname}-${version}"; </del> pname = "CherryPy"; version = "14.0.1";

buildInputs = [ setuptools_scm ]; <del> checkInputs = [ backports_unittest-mock codecov coverage objgraph pathpy pytest pytest-sugar pytestcov ]; </del> <ins> checkInputs = [ backports_unittest-mock objgraph pathpy pytest pytestcov ]; </ins> checkPhase = '' LANG=en_US.UTF-8 pytest

{ stdenv, buildPythonPackage, fetchPypi <del> , pytest, pytest-sugar, pytest-warnings, setuptools_scm , tempora }: </del> <ins> , pytest, setuptools_scm, tempora }: </ins> buildPythonPackage rec { <del> name = "${pname}-${version}"; </del> pname = "portend"; version = "2.2"; <del> buildInputs = [ pytest pytest-sugar pytest-warnings setuptools_scm ]; propagatedBuildInputs = [ tempora ]; </del> src = fetchPypi { inherit pname version; sha256 = "bc48d3d99e1eaf2e9406c729f8848bfdaf87876cd3560dc3ec6c16714f529586"; }; <ins> nativeBuildInputs = [ setuptools_scm ]; propagatedBuildInputs = [ tempora ]; checkInputs = [ pytest ]; checkPhase = '' py.test ''; </ins> meta = with stdenv.lib; { description = "Monitor TCP ports for bound or unbound states"; homepage = https://github.com/jaraco/portend;

description = "A plugin that changes the default look and feel of py.test"; homepage = https://github.com/Frozenball/pytest-sugar; license = licenses.bsd3; <ins> # incompatible with pytest 3.5 # https://github.com/Frozenball/pytest-sugar/issues/134 broken = true; # 2018-04-20 </ins> }; }
Change:
uses url = "{repo}${rev}"; which always downloads tip of default branch at the moment. According to documentation should be used as url parameter instead of but that doesn't work either. and look at the NEWS file in the archive, it mentions v3.3.14. Change one digit in the hash for procps-ng in nixpkgs, to make nix-build redownload the source and watch the hash change completely. It is not really i nixpkgs issue, but we need to work around here. The URL works correctly, but isn't documented. I will make a pr to use that url instead. suggests it will become the official url for fetching archives from
see
New information in so the archive url with "official" long term stability would be: . Beware in the original issue, there is a typo in the project name. Should we jump ahead and change the URL again, to use the official long term stable url?
yes

Discussion:
... # For hash agility }@args: fetchzip ({ inherit name; <del> url = "https://gitlab.com/${owner}/${repo}/repository/archive.tar.gz?ref=${rev}"; </del> <ins> url = "https://gitlab.com/${owner}/${repo}/-/archive/${rev}/${repo}-${rev}.tar.gz"; </ins> meta.homepage = "https://gitlab.com/${owner}/${repo}/"; } // removeAttrs args [ "owner" "repo" "rev" ]) // { inherit rev; };