jiebi/CodeConvo huggingface dataset:
Code change:
, xhtml1 , yajl , writeScript <ins> , nixosTests </ins> # Linux , acl ? null

Related discussion:
text: I sometimes create a qemu VM in libvirt in "session mode", meaning that the libvirt daemon is running as my non-root user, and the system-wide libvirtd does not need to be running (). This VM has a network bridge, which libvirt apparently creates by calling , which in turn uses . The problem is that doesn't get fully populated until the system libvirtd gets started. Previously, in nixpkgs (from February), this wasn't noticeable because libvirtd.service was WantedBy libvirt-guests.service (which is WantedBy multi-), so libvirtd would always be started on boot to populate that directory. Now, with , this is no longer the case, and libvirtd.service does not get started (presumably, if libvirt-guests.service actually needed to start a VM, then libvirtd.service would be socket-activated, but for me this is not the case). As a result, doesn't get populated and my session-mode libvirt can't find . python: The VM's XML file defines a network bridge, which is why gets involved. the following output: The libvirt user session should be usable without first starting the system-wide libvirtd. If you start (and optionally stop) the system libvirtd.service before following the steps to reproduce, everything works fine, because the directory gets populated. Probably, should be put somewhere else, where session-mode daemons can use it without needing to have previously started system-mode libvirtd. (The same may be true of other stuff in too.) libvirt maintainers: Okay, but I'm using flakes and that channel looks old. See relevant commit hashes above.
Oof, happy to find this, it would have taken me a long time to figure out I needed to run first. Can't the sudo wrapper point to the file in the nix store?
Code change:
${stdenv.lib.optionalString enablePlayer '' --prefix LD_LIBRARY_PATH : ${vlc}/lib ''} <ins> mkdir -p $out/share/applications $out/share/icons $out/share/man/man1 cp $out/Tribler/Main/Build/Ubuntu/tribler.desktop $out/share/applications/tribler.desktop cp $out/Tribler/Main/Build/Ubuntu/tribler_big.xpm $out/share/icons/tribler.xpm cp $out/Tribler/Main/Build/Ubuntu/tribler.1 $out/share/man/man1/tribler.1 </ins> ''; meta = with stdenv.lib; {

Related discussion:
text: Describe the bug Tribler does not have any desktop icons, and does not show up in any menus. There is a desktop file in But it's not being included by the desktop environment. Maintainer information:
Code change:
inherit (darwin.apple_sdk.frameworks) Security; }; <ins> vdirsyncerStable = callPackage ../tools/misc/vdirsyncer/stable.nix { }; </ins> vdpauinfo = callPackage ../tools/X11/vdpauinfo { }; verbiste = callPackage ../applications/misc/verbiste {

Related discussion:
text: fails with the vdirsyncer version from nixos-unstable. it works if I install vdirsyncer with pip. Output of :
Which do you get via ? Is it the old 0.16 branch or the new 0.17 one (which was mostly rewritten in rust)? We have the latest git version of 0.17 in nixpkgs. Unfortunately, so it might be some time before this bug is fixed.
outputs this:
Same problem here. Was there any reason to go for an alpha release except for the issue referenced in ? If not, a downgrade to 0.16.7 should be fine, since the original bug is still open and probably won't be fixed for a while without anyone maintaining vdirsyncer.
There are , so I'd rather not downgrade. I'd be happy with a package for the 0.16 branch though.
That'd be great! I haven't looked into packaging yet, so it would take some time if I tried. Would you mind helping out?
I just opened a PR. It’s my first time contributing to , so I hope it’s up to snuff.
Code change:
case $o in init=*) IFS== read -r -a initParam <<< "$o" <del> closure="$(dirname "''${initParam[1]}")" </del> <ins> closure="''${initParam[1]}" </ins> ;; esac done

Related discussion:
text: The script does not (consistently) follow symlinks in the parameter, which it uses to locate the system closure to activate. This breaks when used with , which creates a symlink. When the kernel command line has , the script looks for , which does not exist. ~(Workaround: generationsDir users can pass instead.)~ Update: That doesn't work either. with will fail in strange ways, ultimately stemming from not calling . System should boot successfully when using generationsDir and systemd-initrd together. Symlink resolution was partially addressed in , but only for cases where is a symlink. Booting also fails if the given is a symlink, or if any part of the path to is an absolute symlink (because filesystems are mounted at , not ). I took a stab at fixing this in (), but it does not handle absolute symlinks correctly. Since generationsDir creates absolute symlinks to , this fix alone does not fix compatibility. ( changes those symlinks to relative, and together the PRs fix the compatibility issue.) Ideally, the script should follow symlinks in any part of the param, even if they cross filesystems. One option is to resolve the links inside the chroot. I couldn't figure out a clean way to make this work. (Can we trust that will have the we're looking for? We can't use because we're still trying to establish which system that is.) Another option is to somehow . (At time of writing, this question has no answers.) (guessing based on git log):
Code change:
let pname = "expressvpn"; <del> clientVersion = "3.25.0"; clientBuild = "13"; </del> <ins> clientVersion = "3.52.0"; clientBuild = "2"; </ins> version = lib.strings.concatStringsSep "." [ clientVersion clientBuild ]; expressvpnBase = stdenvNoCC.mkDerivation {

Related discussion:
text: Package name: expressvpn Latest released version: 3.52.0.2 Current version on the unstable channel: 3.25.0.13 Current version on the stable/release channel: 3.25.0.13 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Code change:
'' + optionalString targetPlatform.isAndroid '' <del> echo "-D__ANDROID_API__=${targetPlatform.sdkVer}" >> $out/nix-support/cc-cflags </del> <ins> echo "-D__ANDROID_API__=${targetPlatform.androidSdkVersion}" >> $out/nix-support/cc-cflags </ins> '' # There are a few tools (to name one libstdcxx5) which do not work

Related discussion:
text: Steps to reproduce the behavior: to build (required by ) fail Full trace (libxml2): Doesn't happen on , before I have no idea if this happens on any other platforms, needs triage. I also have no idea why python for linux needs something darwin?!? This also breaks the evaluation of , but not Python team <!-- You know a bunch about splicing --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
<del> { stdenv, fetchurl, perl, git }: </del> <ins> { stdenv, fetchurl, git, nettools, perl }: </ins> stdenv.mkDerivation rec { name = "gitolite-${version}"; <del> version = "3.6.2"; </del> <ins> version = "3.6.3"; </ins> src = fetchurl { url = "https://github.com/sitaramc/gitolite/archive/v${version}.tar.gz"; <del> sha256 = "1gsgzi9ayb4rablki3mqr11b0h8db4xg43df660marfpacmkfb01"; </del> <ins> sha256 = "16cxifjxnri719qb6zzwkdf61x5y957acbdhcgqcan23x1mfn84v"; </ins> }; <del> buildInputs = [ perl git ]; </del> <ins> buildInputs = [ git nettools perl ]; </ins> buildPhase = "true"; patchPhase = ''

Related discussion:
text: I don't know much more than this: and but I don't know how to fix this.
I was bit by this as well. It fails on other key for me -- looks like it would fail on any.
How did you solve this issue?
Can someone tell me where this "keydir" should be located? I cannot find it in my !
The keydir should be in your gitolite datadir, which is /var/lib/gitolite in the default settings.
Okay. My shows:
oh it should be in "/var/lib/gitolite/.gitolite/keydir", my bad.
Okay, everything is there. How to check why it fails?
It failed for me for every key on v3.6.2. So, besides upgrading gitolite to v3.6.3, there is not really much you can do.
Update solved the issue.
Code change:
stumpwm = sbclPackages.stumpwm; <ins> stumpwm-unwrapped = sbclPackages.stumpwm-unwrapped; </ins> sublime = callPackage ../applications/editors/sublime/2 { }; sublime3Packages = recurseIntoAttrs (callPackage ../applications/editors/sublime/3/packages.nix { });

Related discussion:
text: Since PM stumpwm is now up to date but I have an issue in stumpwm module loading. SBCL will return the a package conflict error between packages "CLOSER-COMMON-LISP" and "DYNAMIC-MXINS" Steps to reproduce the behavior: to your stumpwm contrib modules in an appropriate directory a minimal file: reboot using stumpwm or refresh the stumpwm config using command (by default keystrokes are: ) Modules are loaded as expected Results of :
Hm, indeed. And maybe for debugging we should provide access to the «library» version of StumpWM…
We could try building using the Makefile instead of save-lisp-and-die. I did, but then there were problems with missing HOME. Then the problem was that the stumpwm build script seems to want to remember the value of HOME from compile-time on run-time (something like "/build") How did stumpwm work previously in nixpkgs?
Can you try with this?
Code change:
{ description = stdenv.lib.attrByPath ["meta" "description"] "System binary utilities" bintools_ + " (wrapper script)"; <ins> priority = 10; </ins> } // optionalAttrs useMacosReexportHack { platforms = stdenv.lib.platforms.darwin; };

Related discussion:
text: I have installed a very barebones server with NixOS. Whenever I run it shows the following warnings: I get that it does not matter that much which of these are used, but it makes these commands not very transparent. Why is being used from and not , while is apparently part of ? Should we make sure these packages will not both be part of or should we make sure the files are only available in one of the two packages? up a minimal version of NixOS. the log
These are usually fixable by just setting priority values. coreutils should probably have a lower priority as they are usually cross platform but not as many supported features. The getconf and getent are interesting because they are actually symlinks to glibc. But we might as well make unixtools lower priority as well.
Is this something we should do nixpkgs-wide? Will that avoid the warning messages? I was thinking why these are providing the same files and why both packages are being used. For instance, do we really need openresolv or is that included unintentionally? The priorities is a way to solve this safely, but I feel like there shouldn't be any conflicts for the base packages at all.
Maybe openresolv we can leave out of systemPackages. But, some of these collisions are kind of unavoidable. We need both procps and coreutils even though they both provide kill bunary. It might be interesting to see which other distros use but IIRC they are almost identical
For coreutils, ArchLinux seems to leave out the kill binary: This also feels a bit wrong, as it isn't the original package anymore. Changing the priority does indeed sound like a better option. Coreutils should have a lower priority.
I tried giving coreutils a lower priority, but it doesn't seem to have made a difference for those warnings.
oh it already has lowprio: but it doesn't really work when everything has the same priority.
systemd-resolved is not enable by default so resolvconf shouln't be really pointing to resolvectl. I think the dummy command provided for compatibility doesn't work correctly if resolved is not running and dhcpcd needs it to configure interfaces.
Should we just give openresolv a higher priority than systemd?
Yes, correct.
Code change:
{ description = stdenv.lib.attrByPath ["meta" "description"] "System binary utilities" bintools_ + " (wrapper script)"; <ins> priority = 10; </ins> } // optionalAttrs useMacosReexportHack { platforms = stdenv.lib.platforms.darwin; };

Related discussion:
text: The dhcpcd resolvconf hook check if resolvconf is installed and, because the command is in the PATH, it won't fall back to writing directly but will attempt to execute something like this: echo 'nameserver 10.0.1.1' | resolvconf -a wlan0 Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.
Reproducible way to see these collisions: With a file set to I ran in the (the latest commit on the branch), and I get these collision messages:
ping
Hi all nixos-version 03. (Koi) I have the same collision on kill gnutar resolvconf but also on collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/128x128/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/64x64/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/22x22/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/16x16/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/scalable/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.
Code change:
{ description = stdenv.lib.attrByPath ["meta" "description"] "System binary utilities" bintools_ + " (wrapper script)"; <ins> priority = 10; </ins> } // optionalAttrs useMacosReexportHack { platforms = stdenv.lib.platforms.darwin; };

Related discussion:
text: 0/share/icons/hicolor/48x48/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/128x128/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/64x64/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/22x22/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/16x16/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/scalable/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/48x48/apps/phonon-'
This seems to include many more collisions than related to this issue.
Maybe rather than changing the nix-env priority, a better solution is to remove some of these programs (e.g. delete in util-linux's ).
That seems hacky to me. What if you want util-linux's version of kill? Presumably if the maintainer thinks it's worth including, someone has a use for it. Nixpkgs shouldn't be making these decisions at the derivation level. Something like meta seems ideal because you can change it without effecting the derivation.
Since and were merged, does that mean this issue can be closed now?
I think so, I don't see these collisions anymore.
Let me know if this isn't fixed after all.
sorry, but i see these collisions.
Code change:
{ description = stdenv.lib.attrByPath ["meta" "description"] "System binary utilities" bintools_ + " (wrapper script)"; <ins> priority = 10; </ins> } // optionalAttrs useMacosReexportHack { platforms = stdenv.lib.platforms.darwin; };

Related discussion:
text: it's a different issue: it seems you're installing both the wrapped and unwrapped version of the same packages. I'd say there's something wrong with your configuration, but if you think otherwise open a new issue.
Code change:
{ lib, stdenv, fetchurl, cmake, bison, pkg-config , boost, libedit, libevent, lz4, ncurses, openssl, protobuf, readline, zlib, perl , cctools, CoreServices, developer_cmds <del> , libtirpc, rpcsvc-proto </del> <ins> , libtirpc, rpcsvc-proto, nixosTests </ins> }: # Note: zlib is not required; MySQL can use an internal zlib.

Related discussion:
text: , CVSSv3=5.5 (nixos-21.11, nixos-unstable) CVSSv3=4.9 (nixos-21.11, nixos-unstable) CVSSv3=4.9 (nixos-21.11, nixos-unstable) CVSSv3=4.9 (nixos-21.11, nixos-unstable) CVSSv3=4.9 (nixos-21.11, nixos-unstable) CVSSv3=4.3 (nixos-21.11, nixos-unstable) Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Compiling). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Federated). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Stored Procedure). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior.
Code change:
{ lib, stdenv, fetchurl, cmake, bison, pkg-config , boost, libedit, libevent, lz4, ncurses, openssl, protobuf, readline, zlib, perl , cctools, CoreServices, developer_cmds <del> , libtirpc, rpcsvc-proto </del> <ins> , libtirpc, rpcsvc-proto, nixosTests </ins> }: # Note: zlib is not required; MySQL can use an internal zlib.

Related discussion:
text: Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Parser). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 4.3 (Integrity impacts).
Code change:
{ lib, stdenv, fetchurl, cmake, bison, pkg-config , boost, libedit, libevent, lz4, ncurses, openssl, protobuf, readline, zlib, perl , cctools, CoreServices, developer_cmds <del> , libtirpc, rpcsvc-proto </del> <ins> , libtirpc, rpcsvc-proto, nixosTests </ins> }: # Note: zlib is not required; MySQL can use an internal zlib.

Related discussion:
text: CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N). Scanned versions: nixos-21.11: ; nixos-unstable: .
See also: , , , , , ,
Fixed: nixos-21.11: mysql-5.7.37, mysql-8.0.28 nixos-unstable: mysql-5.7.39, mysql-8.0.30
Code change:
<del> { stdenv, python37Packages, fetchFromGitHub, fetchurl, dialog, autoPatchelfHook }: </del> <ins> { lib , buildPythonApplication , fetchFromGitHub , ConfigArgParse, acme, configobj, cryptography, distro, josepy, parsedatetime, pyRFC3339, pyopenssl, pytz, requests, six, zope_component, zope_interface , dialog, mock, gnureadline , pytest_xdist, pytest, dateutil }: </ins> <del> python37Packages.buildPythonApplication rec { </del> <ins> buildPythonApplication rec { </ins> pname = "certbot"; <del> version = "1.0.0"; </del> <ins> version = "1.3.0"; </ins> src = fetchFromGitHub { owner = pname; repo = pname; rev = "v${version}"; <del> sha256 = "180x7gcpfbrzw8k654s7b5nxdy2yg61lq513dykyn3wz4gssw465"; </del> <ins> sha256 = "1nzp1l63f64qqp89y1vyd4lgfhykfp5dkr6iwfiyf273y7sjwpsa"; </ins> }; patches = [ ./0001-Don-t-use-distutils.StrictVersion-that-cannot-handle.patch ]; <del> propagatedBuildInputs = with python37Packages; [ </del> <ins> propagatedBuildInputs = [ </ins> ConfigArgParse acme configobj

Related discussion:
text: Update certbot Current packaged version is 0.39.0, upstream version is 1.2.0.
Fix in
Code change:
fi poolImported "${pool}" || poolImport "${pool}"  # Try one last time, e.g. to import a degraded pool. fi <del> ${lib.optionalString cfgZfs.requestEncryptionCredentials '' zfs load-key -a ''} </del> <ins> ${if isBool cfgZfs.requestEncryptionCredentials then optionalString cfgZfs.requestEncryptionCredentials '' zfs load-key -a '' else concatMapStrings (fs: '' zfs load-key ${fs} '') cfgZfs.requestEncryptionCredentials} </ins> '') rootPools)); };

Related discussion:
text: Describe the bug I have a ZFS pool with approximately the following layout: The datasets under are those that the local system is installed on and the datasets under are backups from a different machine received via . All datasets are using native ZFS encryption, however, datasets under are encrypted with a different key (that of the machine that sent the backups) than the rest of the pool. When I boot, the initrd will query me for the key for and but this key is not available and I also don't want to make it available for obvious reasons. The culprit lies in this statement in the : This forces loading of all keys, which is a good default, but cannot easily be overridden. My current workaround for this is to turn this off and only load the key for manually. To this end I would like to propose the following patch by which it should be possible to load the key only for the specified datasets. To Reproduce Steps to reproduce the behavior: NixOS with an encrypted ZFS pool a dataset with a different encryption key and set you lost the key for this new dataset errors when mounting due to the lack of keys Expected behavior It should be possible to restrict for which pools and datasets to query encryption credentials. Screenshots N/A Additional context N/A Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
I think you can open a PR with your patch for this one.
Code change:
libXxf86vm openal libGLU libGL libjpeg flac libXi libXfixes <del> enet libtheora freetype physfs libopus pkg-config gtk2 pcre libXdmcp </del> <ins> enet libtheora freetype physfs libopus pkg-config gtk3 pcre libXdmcp </ins> libpulseaudio libpthreadstubs ];

Related discussion:
text: RTS/game with programming on simplified C Metadata version: 1.3 homepage URL: source URL: license: GPLv3 platforms: GNU/Linux, Windows, IOS