jiebi/CodeConvo huggingface dataset:
Code change:
With and , I still have to type my LUKS passphrase in qwerty. The logs say this: but not much else apparently. The vconsole is set up fine by the time I get a login prompt.
Dup of

Related discussion:
text: "${config.boot.initrd.systemd.package}/lib/systemd/systemd-vconsole-setup" "${config.boot.initrd.systemd.package.kbd}/bin/setfont" "${config.boot.initrd.systemd.package.kbd}/bin/loadkeys" <del> "${config.boot.initrd.systemd.package.kbd.gzip}/bin/gzip" # keyboard layouts are compressed </del> <ins> "${config.boot.initrd.systemd.package.kbd.gzip}/bin/gzip" # Fonts and keyboard layouts are compressed ] ++ optionals (hasPrefix builtins.storeDir cfg.font) [ "${cfg.font}" ] ++ optionals (hasPrefix builtins.storeDir cfg.keyMap) [ "${cfg.keyMap}" </ins> ]; systemd.services.reload-systemd-vconsole-setup =
Code change:
Can anybody provide a pointer on why allowing dangling commits to be fetched is a security risk? I can't seem to find any details on this. Is the risk because people assume "unreachable" means "deleted"?
There's a guess in is the original author of the documentation (see )
Hrm, that guess has to do with github's PRs, not with anything in git.
Well, I found a reason why git would want to prohibit this, but it isn't related to security. If you a branch, the commit that used to point to is still available in the repository -- at least until the next happens. If people are allowed to fetch commits by their hash even when those commits are unreachable, a force-push like this would put those commits at risk of being garbage collected. But nobody would notice the breakage until (potentially) much later, when a happened, and by then it will be too late to recover the lost commit. But since users are forced to mention a commit from which their desired ref is reachable, they will notice the breakage immediately. Most important of all, they will notice while there is probably still time to rescue the now-gc-able commit. I think this is the reason. If nobody else can come up with a security-related explanation I'm going to submit a PR to remove the word "security" in .

Related discussion:
text: /* NOTE: fetchgit has one problem: git fetch only works for refs. <del> This is because fetching arbitrary (maybe dangling) commits may be a security risk </del> <ins> This is because fetching arbitrary (maybe dangling) commits creates garbage collection risks </ins> and checking whether a commit belongs to a ref is expensive. This may change in the future when some caching is added to git (?) Usually refs are either tags (refs/tags/*) or branches (refs/heads/*)
Code change:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

Related discussion:
text: interpreter = ( poetry2nix.mkPoetryPackages { projectDir = ./.; <ins> python = pkgs.python39; </ins> overrides = [ poetry2nix.defaultPoetryOverrides (import ./poetry-git-overlay.nix { inherit pkgs; })
Code change:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

Related discussion:
text: [[package]] name = "boto3" <del> version = "1.24.6" </del> <ins> version = "1.24.16" </ins> description = "The AWS SDK for Python" category = "main" optional = false python-versions = ">= 3.7" [package.dependencies] <del> botocore = ">=1.27.6,<1.28.0" </del> <ins> botocore = ">=1.27.16,<1.28.0" </ins> jmespath = ">=0.7.1,<2.0.0" s3transfer = ">=0.6.0,<0.7.0"
Code change:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

Related discussion:
text: [[package]] name = "botocore" <del> version = "1.27.6" </del> <ins> version = "1.27.16" </ins> description = "Low-level, data-driven core of boto 3." category = "main" optional = false
Code change:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

Related discussion:
text: [[package]] name = "certifi" <del> version = "2022.5.18.1" </del> <ins> version = "2022.6.15" </ins> description = "Python package for providing Mozilla's CA Bundle." category = "main" optional = false
Code change:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

Related discussion:
text: [[package]] name = "jmespath" <del> version = "1.0.0" </del> <ins> version = "1.0.1" </ins> description = "JSON Matching Expressions" category = "main" optional = false
Code change:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

Related discussion:
text: [metadata] lock-version = "1.1" <del> python-versions = "^3.8" content-hash = "57d7c155ae4259912291b1315f9c2fd6c918fad9ef54d1e8011f800b649f9647" </del> <ins> python-versions = "^3.9" content-hash = "781bb4378f4491b427372322c3ec71131ed7a28e0a166e0bc43969b016b5d926" </ins> [metadata.files] apache-libcloud = [
Code change:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

Related discussion:
text: {file = "boto-2.49.0.tar.gz", hash = "sha256:ea0d3b40a2d852767be77ca343b58a9e3a4b00d9db440efb8da74b4e58025e5a"}, ] boto3 = [ <del> {file = "boto3-1.24.6-py3-none-any.whl", hash = "sha256:1c13d555172cf88eb645af2429e4a7f42be85e365d6ffc110c952a556d3f8808"}, {file = "boto3-1.24.6.tar.gz", hash = "sha256:4af6a8bc5110b5f9d2fbd00a3c110e4c4cc36fae78d05afa354831f5789e363b"}, </del> <ins> {file = "boto3-1.24.16-py3-none-any.whl", hash = "sha256:2c6f7e4103d41ca07d6b934a6612e4b9a2666eae36e8289f88726868534b8de2"}, {file = "boto3-1.24.16.tar.gz", hash = "sha256:422c000ff2ee5226e89fe427a9c4c09db095d69c179a3bcc3cfba37cbc5e787e"}, </ins> ] botocore = [ <del> {file = "botocore-1.27.6-py3-none-any.whl", hash = "sha256:eeebe304161db6828413dc358ea80ece52f4ddbc8ecde4dd58978d5861a09293"}, {file = "botocore-1.27.6.tar.gz", hash = "sha256:97c909a6ec5ad421573c18ae67fc6ea4232502cd30cffaf03bfcb584d9df652d"}, </del> <ins> {file = "botocore-1.27.16-py3-none-any.whl", hash = "sha256:f117d59899d21beeb200130d7af2090a8112d702a06e2c2794ef576bcea36773"}, {file = "botocore-1.27.16.tar.gz", hash = "sha256:b3b9710902f675a11f5bfd46afda770150530876ae6541d099584462bf949fd1"}, </ins> ] certifi = [ <del> {file = "certifi-2022.5.18.1-py3-none-any.whl", hash = "sha256:f1d53542ee8cbedbe2118b5686372fb33c297fcd6379b050cca0ef13a597382a"}, {file = "certifi-2022.5.18.1.tar.gz", hash = "sha256:9c5705e395cd70084351dd8ad5c41e65655e08ce46f2ec9cf6c2c08390f71eb7"}, </del> <ins> {file = "certifi-2022.6.15-py3-none-any.whl", hash = "sha256:fe86415d55e84719d75f8b69414f6438ac3547d2078ab91b67e779ef69378412"}, {file = "certifi-2022.6.15.tar.gz", hash = "sha256:84c85a9078b11105f04f3036a9482ae10e4621616db313fe045dd24743a0820d"}, </ins> ] cffi = [ {file = "cffi-1.15.0-cp27-cp27m-macosx_10_9_x86_64.whl", hash = "sha256:c2502a1a03b6312837279c8c1bd3ebedf6c12c4228ddbad40912d671ccc8a962"},
Code change:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

Related discussion:
text: {file = "idna-3.3.tar.gz", hash = "sha256:9d643ff0a55b762d5cdb124b8eaa99c66322e2157b69160bc32796e824360e6d"}, ] jmespath = [ <del> {file = "jmespath-1.0.0-py3-none-any.whl", hash = "sha256:e8dcd576ed616f14ec02eed0005c85973b5890083313860136657e24784e4c04"}, {file = "jmespath-1.0.0.tar.gz", hash = "sha256:a490e280edd1f57d6de88636992d05b71e97d69a26a19f058ecf7d304474bf5e"}, </del> <ins> {file = "jmespath-1.0.1-py3-none-any.whl", hash = "sha256:02e2e4cc71b5bcab88332eebf907519190dd9e6e82107fa7f83b1003a6252980"}, {file = "jmespath-1.0.1.tar.gz", hash = "sha256:90261b206d6defd58fdd5e85f478bf633a2901798906be2ad389150c5c60edbe"}, </ins> ] jsonpickle = [ {file = "jsonpickle-2.2.0-py2.py3-none-any.whl", hash = "sha256:de7f2613818aa4f234138ca11243d6359ff83ae528b2185efdd474f62bcf9ae1"},
Code change:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

Related discussion:
text: authors = ["Adam Hoese <adam.hose@tweag.io>"] [tool.poetry.dependencies] <del> python = "^3.8" </del> <ins> python = "^3.9" </ins> nixops = {git = "https://github.com/NixOS/nixops.git"} nixops-aws = {git = "https://github.com/NixOS/nixops-aws.git"} nixops-digitalocean = {git = "https://github.com/nix-community/nixops-digitalocean.git"}
Code change:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)

Related discussion:
text: pkgs.poetry2nix.cli pkgs.pkg-config pkgs.libvirt <del> pkgs.poetry </del> <ins> pkgs.python39Packages.poetry </ins> ]; }
Code change:
Project description vibrantLinux is a GUI tool to serves the same purpose as for Windows, which to modify the saturation of any given screen whenever certain programs are launched/are in focus. Metadata homepage URL: source URL: license: MIT platforms: Linux Only
Bump. I have some low vision issues and "vibrance" makes it much easier to read the screen. Thanks!

Related discussion:
text: <ins> { lib , stdenv , fetchFromGitHub , cmake , makeWrapper , libX11 , libXrandr , linuxPackages }: stdenv.mkDerivation rec { pname = "libvibrant"; version = "2100c09"; src = fetchFromGitHub { owner = "libvibrant"; repo = "libvibrant"; rev = version; hash = "sha256-nVODwP/PQgYBTHnSplgrkdNOLsF7N+vZ8iPL7gArVNY="; }; buildInputs = [ libX11 libXrandr linuxPackages.nvidia_x11.settings.libXNVCtrl ]; nativeBuildInputs = [ cmake makeWrapper ]; meta = with lib; { description = "A simple library to adjust color saturation of X11 outputs"; homepage = "https://github.com/libvibrant/libvibrant"; license = licenses.mit; platforms = platforms.linux; mainProgram = "vibrant-cli"; }; } </ins>
Code change:
Project description vibrantLinux is a GUI tool to serves the same purpose as for Windows, which to modify the saturation of any given screen whenever certain programs are launched/are in focus. Metadata homepage URL: source URL: license: MIT platforms: Linux Only
Bump. I have some low vision issues and "vibrance" makes it much easier to read the screen. Thanks!

Related discussion:
text: <ins> { lib , stdenv , fetchFromGitHub , qt5 , makeWrapper , libvibrant , libX11 , libXrandr , libxcb , linuxPackages }: stdenv.mkDerivation rec { pname = "vibrantLinux"; version = "2.1.10"; src = fetchFromGitHub { owner = "libvibrant"; repo = "vibrantLinux"; rev = version; hash = "sha256-rvJiVId6221hTrfEIvVO9HTMhaZ6KY44Bu3a5MinPHI="; }; nativeBuildInputs = [ makeWrapper ] ++ (with qt5; [ qmake wrapQtAppsHook ]); buildInputs = [ libX11 libXrandr libxcb libvibrant linuxPackages.nvidia_x11.settings.libXNVCtrl ] ++ (with qt5; [ qtbase qttools ]); postPatch = '' substituteInPlace vibrantLinux.pro  --replace '$$(PREFIX)' '$$PREFIX' ''; meta = with lib; { description = "A tool to automate managing your screen's saturation depending on what programs are running"; homepage = "https://github.com/libvibrant/vibrantLinux"; license = licenses.mit; maintainers = with maintainers; [ unclamped ]; platforms = platforms.linux; mainProgram = "vibrantLinux"; }; } </ins>
Code change:
Steps to reproduce the behavior: Added 'kanboard' to Then ran My machine: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.

Related discussion:
text: owner = "kanboard"; repo = "kanboard"; rev = "v${version}"; <del> sha256 = "sha256-pLxCm+T9jdn0FFqbTFe1tsIPTaVTT+QDeLHDxrbpGBg="; </del> <ins> sha256 = "sha256-WG2lTPpRG9KQpRdb+cS7CqF4ZDV7JZ8XtNqAI6eVzm0="; </ins> }; dontBuild = true;
Code change:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: rustup <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.24.3 desired version: 1.25.1 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.

Related discussion:
text: rustPlatform.buildRustPackage rec { pname = "rustup"; <del> version = "1.24.3"; </del> <ins> version = "1.25.1"; </ins> src = fetchFromGitHub { owner = "rust-lang"; repo = "rustup"; rev = version; <del> sha256 = "sha256-JpOOFwlTgwwBCrXOGYskFTgS6RZ7mHQJGT0jnHavxvI="; </del> <ins> sha256 = "sha256-zCr8xu0j/pBsdJEAYTCGrEouA8QumBnyhM4YLFZJqZI="; </ins> }; <del> cargoSha256 = "sha256-hAfGpKaWD94IxFFpnW9XwQp4P9clUX6mmekwodCK0Ag="; </del> <ins> cargoSha256 = "sha256-FDVZn2PjqxovQmmandJICkidurhoXCAxo3bibuxQSMY="; </ins> nativeBuildInputs = [ makeWrapper pkg-config ];
Code change:
Linux kernel 4.6 on the stable channel cannot be compiled due to an outdated patch. The patch is removed from the master by the commit but it is not removed from the stable channel. Please backport the commit.
Cc

Related discussion:
text: # TODO add plugins having various licenses, see http://www.vamp-plugins.org/download.html <del> { stdenv, fetchurl, alsaLib, bzip2, fftw, jackaudio, libX11, liblo, libmad, libogg, librdf, librdf_raptor, librdf_rasqal, libsamplerate, libsndfile, makeWrapper, pulseaudio, qt4, redland, rubberband, vampSDK </del> <ins> { stdenv, fetchurl, alsaLib, bzip2, fftw, jackaudio, libX11, liblo , libmad, libogg, librdf, librdf_raptor, librdf_rasqal, libsamplerate , libsndfile, makeWrapper, pkgconfig, pulseaudio, qt4, redland , rubberband, vampSDK </ins> }: <del> stdenv.mkDerivation { name = "sonic-visualiser-1.8"; </del> <ins> stdenv.mkDerivation rec { name = "sonic-visualiser-${version}"; version = "1.9"; </ins> src = fetchurl { <del> url = http://downloads.sourceforge.net/sv1/sonic-visualiser-1.8.tar.gz; sha256 = "16ik6q9n92wljvnqcv7hyzb9v3yp3ixxp6df9kasf53fii973dh7"; </del> <ins> url = "http://code.soundsoftware.ac.uk/attachments/download/194/${name}.tar.gz"; sha256 = "00igf7j6s8xfyxnlkbqma0yby9pknxqzy8cmh0aw95ix80cw56fq"; </ins> }; buildInputs = [ libsndfile qt4 fftw /* should be fftw3f ??*/ bzip2 librdf rubberband libsamplerate vampSDK alsaLib librdf_raptor librdf_rasqal redland <ins> pkgconfig </ins> # optional jackaudio # portaudio
Code change:
Linux kernel 4.6 on the stable channel cannot be compiled due to an outdated patch. The patch is removed from the master by the commit but it is not removed from the stable channel. Please backport the commit.
Cc

Related discussion:
text: description = "View and analyse contents of music audio files"; homepage = http://www.sonicvisualiser.org/; license = "GPLv2"; <del> maintainers = [ stdenv.lib.maintainers.marcweber stdenv.lib.maintainers.goibhniu ]; </del> <ins> maintainers = [ stdenv.lib.maintainers.marcweber stdenv.lib.maintainers.goibhniu ]; </ins> platforms = stdenv.lib.platforms.linux; }; }
Code change:
The system-wide LDAP client configuration in is ignored by Openldap client programs. Steps to reproduce the behavior: settings into via or any other Openldap client Openldap client programs should obey the system-wide configuration file in . strace shows it's reading the example configuration from the package instead: Since commit the openldap package no longer passes to configure, it only passes to make instead. Please run and paste the result.
It seems a bit dodgy, but this might be a solution: plus corresponding changes to all the packages and tests that refer to . I'm just rebuilding a gazillion packages on my system from source, so I can check if that works properly...
you probably meant to ping and instead
Oops, sorry about that. I forgot that the maintainer handles listed in the package do not necessarily correspond to their Github usernames.
I realised that changing is probably unwise. Not only does it break some other packages (like python-ldap) and some Nixos tests, it will also break any users who have configured slapd to refer to the schemas under , as I myself have: And changing is not necessary to fix the bug anyway. It seems that the approach of passing differently in compile and install works. I'll send a PR for it.

Related discussion:
text: objectClass: organizationalUnit ou: users ''; <ins> ldapClientConfig = { enable = true; loginPam = false; nsswitch = false; server = "ldap://"; base = "dc=example"; }; </ins> testScript = '' machine.wait_for_unit("openldap.service") machine.succeed( <del> 'ldapsearch -LLL -D "cn=root,dc=example" -w notapassword -b "dc=example"', </del> <ins> 'ldapsearch -LLL -D "cn=root,dc=example" -w notapassword', </ins> ) ''; in {
Code change:
The system-wide LDAP client configuration in is ignored by Openldap client programs. Steps to reproduce the behavior: settings into via or any other Openldap client Openldap client programs should obey the system-wide configuration file in . strace shows it's reading the example configuration from the package instead: Since commit the openldap package no longer passes to configure, it only passes to make instead. Please run and paste the result.
It seems a bit dodgy, but this might be a solution: plus corresponding changes to all the packages and tests that refer to . I'm just rebuilding a gazillion packages on my system from source, so I can check if that works properly...
you probably meant to ping and instead
Oops, sorry about that. I forgot that the maintainer handles listed in the package do not necessarily correspond to their Github usernames.
I realised that changing is probably unwise. Not only does it break some other packages (like python-ldap) and some Nixos tests, it will also break any users who have configured slapd to refer to the schemas under , as I myself have: And changing is not necessary to fix the bug anyway. It seems that the approach of passing differently in compile and install works. I'll send a PR for it.

Related discussion:
text: }; declarativeContents."dc=example" = dbContents; }; <ins> users.ldap = ldapClientConfig; </ins> }; }) { inherit pkgs system; };
Code change:
The system-wide LDAP client configuration in is ignored by Openldap client programs. Steps to reproduce the behavior: settings into via or any other Openldap client Openldap client programs should obey the system-wide configuration file in . strace shows it's reading the example configuration from the package instead: Since commit the openldap package no longer passes to configure, it only passes to make instead. Please run and paste the result.
It seems a bit dodgy, but this might be a solution: plus corresponding changes to all the packages and tests that refer to . I'm just rebuilding a gazillion packages on my system from source, so I can check if that works properly...
you probably meant to ping and instead
Oops, sorry about that. I forgot that the maintainer handles listed in the package do not necessarily correspond to their Github usernames.
I realised that changing is probably unwise. Not only does it break some other packages (like python-ldap) and some Nixos tests, it will also break any users who have configured slapd to refer to the schemas under , as I myself have: And changing is not necessary to fix the bug anyway. It seems that the approach of passing differently in compile and install works. I'll send a PR for it.

Related discussion:
text: rootpw = "notapassword"; declarativeContents."dc=example" = dbContents; }; <ins> users.ldap = ldapClientConfig; </ins> }; }) { inherit system pkgs; };
Code change:
The system-wide LDAP client configuration in is ignored by Openldap client programs. Steps to reproduce the behavior: settings into via or any other Openldap client Openldap client programs should obey the system-wide configuration file in . strace shows it's reading the example configuration from the package instead: Since commit the openldap package no longer passes to configure, it only passes to make instead. Please run and paste the result.
It seems a bit dodgy, but this might be a solution: plus corresponding changes to all the packages and tests that refer to . I'm just rebuilding a gazillion packages on my system from source, so I can check if that works properly...
you probably meant to ping and instead
Oops, sorry about that. I forgot that the maintainer handles listed in the package do not necessarily correspond to their Github usernames.
I realised that changing is probably unwise. Not only does it break some other packages (like python-ldap) and some Nixos tests, it will also break any users who have configured slapd to refer to the schemas under , as I myself have: And changing is not necessary to fix the bug anyway. It seems that the approach of passing differently in compile and install works. I'll send a PR for it.

Related discussion:
text: enable = true; configDir = "/var/db/slapd.d"; }; <ins> users.ldap = ldapClientConfig; </ins> }; testScript = let