jiebi/CodeConvo huggingface dataset:
Code change:
ACME certificates cannot be provisioned automatically, even though run in manual mode succeeds. This seems to occur whenever allocating a new certificate, and possibly when renewing one. System: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: "16.03.1168."
Hi guys; if any of you know what's going on here, it'd be greatly appreciated. From what I can tell, the Terms of Service are out of date for nixpkgs's version of letsencrypt - and this makes the service pretty much unusable. If you have any ideas about how we can fix this, I'll be happy to investigate further and make a fix.
Luckily only happens when creating a new account, so renews are not affected. Thanks for reporting. Fixed. :beers:
Awesome; thanks for the very fast fix! I'm wondering if there's a more permanent way to solve this - being unable to deploy new servers whenever letsencrypt releases a new TOS seems a bit fragile. Maybe we could add a configuration option to set the TOS hash on the command line when invoking simp_le?
That's a good idea. Also as we're right before releasing 16.09 we should add that option before the release so NixOS users can easily update the hash themselves if needed.
Hi! Even if the new configuration option to set the TOSH hash would only appear in (makes sense, it's a new feature), is the hash fix () going to reach ? It doesn't seem to be there for now:
Thanks for the reminder. I'll look at it. The only potential problem is that is at another version in 16.03. The patch should apply cleanly, though.
any news? If someone need a fix, just add the following snippet to your configuration to override the package with a patched one: Then you can use the options as usual! But I hope the patch will soon be available in :)
Ah, thanks for testing that! In that case I'll simply backport that patch.
Ok, backported. Will be in the 16.03 channel soon. I'll keep this issue open because I want an to add an option for 16.09 to specify the TOS hash in the module.
Confirmed to work on ! Thanks a lot!
are you still planning on doing this in time for 16.09?
what are actionables here for 16.09?
We won't implement this for now because we need to replace simp_le anyway.
This is happening again?
That fix worked for me. I've no idea if it breaks anything else for others.

Related discussion:
text: python2Packages.buildPythonApplication rec { name = "certbot-${version}"; <del> version = "0.11.1"; </del> <ins> version = "0.19.0"; </ins> src = fetchFromGitHub { owner = "certbot"; repo = "certbot"; rev = "v${version}"; <del> sha256 = "0f8s6wzj69gnqld6iaskmmwyg5zy5v3zwhp1n1izxixm0vhkzgrq"; </del> <ins> sha256 = "14i3q59v7j0q2pa1dri420fhil4h0vgl4vb471hp81f4y14gq6h7"; </ins> }; propagatedBuildInputs = with python2Packages; [
Code change:
ACME certificates cannot be provisioned automatically, even though run in manual mode succeeds. This seems to occur whenever allocating a new certificate, and possibly when renewing one. System: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: "16.03.1168."
Hi guys; if any of you know what's going on here, it'd be greatly appreciated. From what I can tell, the Terms of Service are out of date for nixpkgs's version of letsencrypt - and this makes the service pretty much unusable. If you have any ideas about how we can fix this, I'll be happy to investigate further and make a fix.
Luckily only happens when creating a new account, so renews are not affected. Thanks for reporting. Fixed. :beers:
Awesome; thanks for the very fast fix! I'm wondering if there's a more permanent way to solve this - being unable to deploy new servers whenever letsencrypt releases a new TOS seems a bit fragile. Maybe we could add a configuration option to set the TOS hash on the command line when invoking simp_le?
That's a good idea. Also as we're right before releasing 16.09 we should add that option before the release so NixOS users can easily update the hash themselves if needed.
Hi! Even if the new configuration option to set the TOSH hash would only appear in (makes sense, it's a new feature), is the hash fix () going to reach ? It doesn't seem to be there for now:
Thanks for the reminder. I'll look at it. The only potential problem is that is at another version in 16.03. The patch should apply cleanly, though.
any news? If someone need a fix, just add the following snippet to your configuration to override the package with a patched one: Then you can use the options as usual! But I hope the patch will soon be available in :)
Ah, thanks for testing that! In that case I'll simply backport that patch.
Ok, backported. Will be in the 16.03 channel soon. I'll keep this issue open because I want an to add an option for 16.09 to specify the TOS hash in the module.
Confirmed to work on ! Thanks a lot!
are you still planning on doing this in time for 16.09?
what are actionables here for 16.09?
We won't implement this for now because we need to replace simp_le anyway.
This is happening again?
That fix worked for me. I've no idea if it breaks anything else for others.

Related discussion:
text: pythonPackages.buildPythonApplication rec { pname = "simp_le-client"; <del> version = "0.2.0"; </del> <ins> version = "0.6.1"; </ins> name = "${pname}-${version}"; src = pythonPackages.fetchPypi { inherit pname version; <del> sha256 = "1zg18jfry9mvkri3yd2f5mwfsl27ac9zmnll3bm93jb91jhd6ssh"; </del> <ins> sha256 = "0x4fky9jizs3xi55cdy217cvm3ikpghiabysan71b07ackkdfj6k"; </ins> }; checkPhase = ''
Code change:
This is from nixos-unstable current. For some reason, I get build failures with ZSH. This is with a nixpkgs (system=x86_64-linux) and nixpkgs.crossSystem set to . This seems to be the same failure (I checked, its the same derivation): Steps to reproduce the behavior: ... ... ... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- 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.
couldn't fix it. I'll leave this assigned to myself so i remember to take a another shot at it in ~6 months
Fixed by

Related discussion:
text: , texinfo , ncurses , pcre <ins> , pkg-config </ins> , buildPackages }: let
Code change:
This is from nixos-unstable current. For some reason, I get build failures with ZSH. This is with a nixpkgs (system=x86_64-linux) and nixpkgs.crossSystem set to . This seems to be the same failure (I checked, its the same derivation): Steps to reproduce the behavior: ... ... ... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- 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.
couldn't fix it. I'll leave this assigned to myself so i remember to take a another shot at it in ~6 months
Fixed by

Related discussion:
text: ]; strictDeps = true; <del> nativeBuildInputs = [ autoreconfHook perl groff texinfo pcre] </del> <ins> nativeBuildInputs = [ autoreconfHook perl groff texinfo pkg-config ] </ins> ++ lib.optionals stdenv.isLinux [ util-linux yodl ]; buildInputs = [ ncurses pcre ];
Code change:
This is from nixos-unstable current. For some reason, I get build failures with ZSH. This is with a nixpkgs (system=x86_64-linux) and nixpkgs.crossSystem set to . This seems to be the same failure (I checked, its the same derivation): Steps to reproduce the behavior: ... ... ... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- 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.
couldn't fix it. I'll leave this assigned to myself so i remember to take a another shot at it in ~6 months
Fixed by

Related discussion:
text: "zsh_cv_sys_dynamic_strip_lib=yes" ]; <ins> preConfigure = '' # use pkg-config instead of pcre-config configureFlagsArray+=("PCRECONF=''${PKG_CONFIG} libpcre") ''; </ins> # the zsh/zpty module is not available on hydra # so skip groups Y Z checkFlags = map (T: "TESTNUM=${T}") (lib.stringToCharacters "ABCDEVW");
Code change:
Project description Metadata homepage URL: source URL: license: Business Source License 1.1, change to Apache License 2.0 on June 1st 2027 platforms: linux
Can you check out my PR if everything works?

Related discussion:
text: </listitem> <listitem> <para> <ins> <link xlink:href="https://dragonflydb.io/">dragonflydb</link>, a modern replacement for Redis and Memcached. Available as <link linkend="opt-services.dragonflydb.enable">services.dragonflydb</link>. </para> </listitem> <listitem> <para> </ins> <link xlink:href="https://github.com/leetronics/infnoise">infnoise</link>, a hardware True Random Number Generator dongle. Available as <link xlink:href="options.html#opt-services.infnoise.enable">services.infnoise</link>.
Code change:
Project description Metadata homepage URL: source URL: license: Business Source License 1.1, change to Apache License 2.0 on June 1st 2027 platforms: linux
Can you check out my PR if everything works?

Related discussion:
text: - [appvm](https://github.com/jollheef/appvm), Nix based app VMs. Available as [virtualisation.appvm](options.html#opt-virtualisation.appvm.enable). <ins> - [dragonflydb](https://dragonflydb.io/), a modern replacement for Redis and Memcached. Available as [services.dragonflydb](#opt-services.dragonflydb.enable). </ins> - [infnoise](https://github.com/leetronics/infnoise), a hardware True Random Number Generator dongle. Available as [services.infnoise](options.html#opt-services.infnoise.enable).
Code change:
Project description Metadata homepage URL: source URL: license: Business Source License 1.1, change to Apache License 2.0 on June 1st 2027 platforms: linux
Can you check out my PR if everything works?

Related discussion:
text: ./services/databases/clickhouse.nix ./services/databases/cockroachdb.nix ./services/databases/couchdb.nix <ins> ./services/databases/dragonflydb.nix </ins> ./services/databases/firebird.nix ./services/databases/foundationdb.nix ./services/databases/hbase.nix
Code change:
Project description Metadata homepage URL: source URL: license: Business Source License 1.1, change to Apache License 2.0 on June 1st 2027 platforms: linux
Can you check out my PR if everything works?

Related discussion:
text: <ins> { fetchFromGitHub , fetchurl , lib , stdenv , double-conversion , gperftools , mimalloc , rapidjson , liburing , xxHash , abseil-cpp_202111 , gbenchmark , glog , gtest , jemalloc , gcc-unwrapped , autoconf , autoconf-archive , automake , cmake , ninja , boost , libunwind , libtool , openssl }: let pname = "dragonflydb"; version = "0.1.0"; src = fetchFromGitHub { owner = pname; repo = "dragonfly"; rev = "v${version}"; hash = "sha256-P6WMW/n+VezWDXGagT4B+ZYyCp8oufDV6MTrpKpLZcs="; fetchSubmodules = true; }; # Needed exactly 5.4.4 for patch to work lua = fetchurl { url = "https://github.com/lua/lua/archive/refs/tags/v5.4.4.tar.gz"; hash = "sha256-L/ibvqIqfIuRDWsAb1ukVZ7c9GiiVTfO35mI7ZD2tFA="; }; in stdenv.mkDerivation { inherit pname version src; postPatch = '' mkdir -p ./build/{third_party,_deps} ln -s ${double-conversion.src} ./build/third_party/dconv ln -s ${mimalloc.src} ./build/third_party/mimalloc ln -s ${rapidjson.src} ./build/third_party/rapidjson ln -s ${gbenchmark.src} ./build/_deps/benchmark-src ln -s ${gtest.src} ./build/_deps/gtest-src cp -R --no-preserve=mode,ownership ${gperftools.src} ./build/third_party/gperf cp -R --no-preserve=mode,ownership ${liburing.src} ./build/third_party/uring cp -R --no-preserve=mode,ownership ${xxHash.src} ./build/third_party/xxhash cp -R --no-preserve=mode,ownership ${abseil-cpp_202111.src} ./build/_deps/abseil_cpp-src cp -R --no-preserve=mode,ownership ${glog.src} ./build/_deps/glog-src chmod u+x ./build/third_party/uring/configure cp ./build/third_party/xxhash/cli/xxhsum.{1,c} ./build/third_party/xxhash patch -p1 -d ./build/_deps/glog-src < ${./glog.patch} sed ' s@REPLACEJEMALLOCURL@file://${jemalloc.src}@ s@REPLACELUAURL@file://${lua}@ ' ${./fixes.patch} | patch -p1 ''; nativeBuildInputs = [ autoconf autoconf-archive automake cmake ninja ]; buildInputs = [ boost libunwind libtool openssl ]; cmakeFlags = [ "-DCMAKE_AR=${gcc-unwrapped}/bin/gcc-ar" "-DCMAKE_RANLIB=${gcc-unwrapped}/bin/gcc-ranlib" ]; ninjaFlags = "dragonfly"; doCheck = false; dontUseNinjaInstall = true; installPhase = '' runHook preInstall mkdir -p $out/bin cp ./dragonfly $out/bin runHook postInstall ''; meta = with lib; { description = "A modern replacement for Redis and Memcached"; homepage = "https://dragonflydb.io/"; license = licenses.bsl11; platforms = platforms.linux; maintainers = with maintainers; [ yureien ]; }; } </ins>
Code change:
Project description Metadata homepage URL: source URL: license: Business Source License 1.1, change to Apache License 2.0 on June 1st 2027 platforms: linux
Can you check out my PR if everything works?

Related discussion:
text: dr14_tmeter = callPackage ../applications/audio/dr14_tmeter { }; <ins> dragonflydb = callPackage ../servers/nosql/dragonflydb { }; </ins> dragonfly-reverb = callPackage ../applications/audio/dragonfly-reverb { }; drawing = callPackage ../applications/graphics/drawing { };
Code change:
As of nixos/nixpkgs (i.e., today) seems to be failing due to an unsupported command line switch being passed (see ) Actually, starting doesn't fail, but some (all?) of the other command line arguments are ignored. For example, I tried setting , but see how insists on starting on port . Removing the switch makes start as expected, respecting the other given command line switches, but is this what we want to do? cc
this was broken due to Catalyst bump. See duplicated - I don't know how to best fix this as switch might have an impact. If someone has time to fix it, I'd be very happy :)

Related discussion:
text: <ins> diff --git a/lib/CatalystX/Script/Server/Starman.pm b/lib/CatalystX/Script/Server/Starman.pm index 670bd74..7b3bd2e 100644 --- a/lib/CatalystX/Script/Server/Starman.pm +++ b/lib/CatalystX/Script/Server/Starman.pm @@ -9,7 +9,7 @@ our $VERSION = '0.02'; extends 'Catalyst::Script::Server'; -has '+fork' => ( default => 1, init_arg => undef ); +has '+fork' => ( default => 1 ); has [qw/ keepalive restart restart_delay restart_regex restart_directory/] => ( init_arg => undef, is => 'ro' ); @@ -70,7 +70,7 @@ CatalystX::Script::Server::Starman - Replace the development server with Starman -d --debug           force debug mode -f --fork            handle each request in a new process -                            (defaults to false) +                            (defaults to true) -? --help            display this help and exits -h --host            host (defaults to all) -p --port            port (defaults to 3000) </ins>
Code change:
As of nixos/nixpkgs (i.e., today) seems to be failing due to an unsupported command line switch being passed (see ) Actually, starting doesn't fail, but some (all?) of the other command line arguments are ignored. For example, I tried setting , but see how insists on starting on port . Removing the switch makes start as expected, respecting the other given command line switches, but is this what we want to do? cc
this was broken due to Catalyst bump. See duplicated - I don't know how to best fix this as switch might have an impact. If someone has time to fix it, I'd be very happy :)

Related discussion:
text: url = mirror://cpan/authors/id/A/AB/ABRAXXA/CatalystX-Script-Server-Starman-0.02.tar.gz; sha256 = "0h02mpkc4cmi3jpvcd7iw7xyzx55bqvvl1qkf967gqkvpklm0qx5"; }; <ins> patches = [ # See Nixpkgs issues #16074 and #17624 ../development/perl-modules/CatalystXScriptServerStarman-fork-arg.patch ]; </ins> buildInputs = [ TestWWWMechanizeCatalyst ]; propagatedBuildInputs = [ CatalystRuntime Moose namespaceautoclean Starman ]; meta = {
Code change:
The systemd-boot image built in nixpkgs has gaps in the section table. This leads to signature verification failure with some UEFI Secure Boot implementations (e.g. Dell XPS 13 9310) Using NixOS 22.05 @ Using some old version from NixOS 21.11 that I still have in the store: N/A Allegedly something like this was fixed in systemd upstream and the commit is present in v250.4 but for some reason it still appears and Secure Boot fails. <!-- 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. system: host os: multi-user?: sandbox: version: nixpkgs:
Relevant:
This commit might be the culprit: I will try confirm this, but since it requires rebuilding systemd, it'll take a while.
It's more likely a problem of sbsigntools:
Does your hardware still correctly validate the signature with this patch applied?
Yes, signature verification works with this patch (and only with this patch). Hardware is Dell XPS 13 9310. See also

Related discussion:
text: <del> --- sbsigntools/configure.ac	2018-09-25 10:30:00.878766256 -0500 +++ configure.ac.new	2018-09-25 10:34:56.231277375 -0500 @@ -71,15 +71,16 @@ </del> <ins> diff --git a/configure.ac b/configure.ac index 4ffb68f..d8a8265 100644 --- a/configure.ac +++ b/configure.ac @@ -71,15 +71,16 @@ AM_CONDITIONAL(TEST_BINARY_FORMAT, [ test "$EFI_ARCH" = "arm" -o "$EFI_ARCH" = " </ins> # no consistent view of where gnu-efi should dump the efi stuff, so find it ## <del> for path in /lib /lib64 /usr/lib /usr/lib64 /usr/lib32 /lib/efi /lib64/efi /usr/lib/efi /usr/lib64/efi; do </del> <ins> for path in /lib /lib64 /usr/lib /usr/lib64 /usr/lib32 /lib/efi /lib64/efi /usr/lib/efi /usr/lib64/efi /usr/lib/gnuefi /usr/lib64/gnuefi ; do </ins> -    if test -e $path/crt0-efi-$EFI_ARCH.o; then -       CRTPATH=$path +    if test -e @@NIX_GNUEFI@@/$path/crt0-efi-$EFI_ARCH.o; then
Code change:
The systemd-boot image built in nixpkgs has gaps in the section table. This leads to signature verification failure with some UEFI Secure Boot implementations (e.g. Dell XPS 13 9310) Using NixOS 22.05 @ Using some old version from NixOS 21.11 that I still have in the store: N/A Allegedly something like this was fixed in systemd upstream and the commit is present in v250.4 but for some reason it still appears and Secure Boot fails. <!-- 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. system: host os: multi-user?: sandbox: version: nixpkgs:
Relevant:
This commit might be the culprit: I will try confirm this, but since it requires rebuilding systemd, it'll take a while.
It's more likely a problem of sbsigntools:
Does your hardware still correctly validate the signature with this patch applied?
Yes, signature verification works with this patch (and only with this patch). Hardware is Dell XPS 13 9310. See also

Related discussion:
text: -DEFI_FUNCTION_WRAPPER" CPPFLAGS_save="$CPPFLAGS" CPPFLAGS="$CPPFLAGS $EFI_CPPFLAGS" <del> @@ -90,5 +91,5 @@ </del> <ins> @@ -90,5 +91,5 @@ AC_SUBST(EFI_ARCH, $EFI_ARCH) </ins> AC_SUBST(CRTPATH, $CRTPATH) AC_CONFIG_FILES([Makefile src/Makefile lib/ccan/Makefile]
Code change:
The systemd-boot image built in nixpkgs has gaps in the section table. This leads to signature verification failure with some UEFI Secure Boot implementations (e.g. Dell XPS 13 9310) Using NixOS 22.05 @ Using some old version from NixOS 21.11 that I still have in the store: N/A Allegedly something like this was fixed in systemd upstream and the commit is present in v250.4 but for some reason it still appears and Secure Boot fails. <!-- 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. system: host os: multi-user?: sandbox: version: nixpkgs:
Relevant:
This commit might be the culprit: I will try confirm this, but since it requires rebuilding systemd, it'll take a while.
It's more likely a problem of sbsigntools:
Does your hardware still correctly validate the signature with this patch applied?
Yes, signature verification works with this patch (and only with this patch). Hardware is Dell XPS 13 9310. See also

Related discussion:
text: , openssl, libuuid, gnu-efi, libbfd }: <del> stdenv.mkDerivation { </del> <ins> stdenv.mkDerivation rec { </ins> pname = "sbsigntool"; <del> version = "0.9.1"; </del> <ins> version = "0.9.4"; </ins> src = fetchgit { url = "https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git"; <del> rev = "v0.9.1"; sha256 = "098gxmhjn8acxjw5bq59wq4xhgkpx1xn8kjvxwdzpqkwq9ivrsbp"; </del> <ins> rev = "v${version}"; sha256 = "sha256-dbjdA+hjII/k7wABTTJV5RBdy4KlNkFlBWEaX4zn5vg="; </ins> }; patches = [ ./autoconf.patch ];
Code change:
The systemd-boot image built in nixpkgs has gaps in the section table. This leads to signature verification failure with some UEFI Secure Boot implementations (e.g. Dell XPS 13 9310) Using NixOS 22.05 @ Using some old version from NixOS 21.11 that I still have in the store: N/A Allegedly something like this was fixed in systemd upstream and the commit is present in v250.4 but for some reason it still appears and Secure Boot fails. <!-- 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. system: host os: multi-user?: sandbox: version: nixpkgs:
Relevant:
This commit might be the culprit: I will try confirm this, but since it requires rebuilding systemd, it'll take a while.
It's more likely a problem of sbsigntools:
Does your hardware still correctly validate the signature with this patch applied?
Yes, signature verification works with this patch (and only with this patch). Hardware is Dell XPS 13 9310. See also

Related discussion:
text: meta = with lib; { description = "Tools for maintaining UEFI signature databases"; homepage    = "http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases"; <del> maintainers = [ maintainers.tstrobel ]; </del> <ins> maintainers = with maintainers; [ hmenke tstrobel ]; </ins> platforms   = [ "x86_64-linux" ]; # Broken on i686 license     = licenses.gpl3; };
Code change:
Project description describe the project a little is a highly configurable dashboard for Neovim. It's an alternative to Metadata homepage URL: source URL: license: MIT platforms: Anything that can run Neovim, I would assume

Related discussion:
text: meta.homepage = "https://github.com/vim-scripts/align/"; }; <ins> alpha-nvim = buildVimPluginFrom2Nix { pname = "alpha-nvim"; version = "2022-04-22"; src = fetchFromGitHub { owner = "goolord"; repo = "alpha-nvim"; rev = "4781fcfea5ddc1a92d41b32dc325132ed6fce7a8"; sha256 = "03i75403lskpgaqv7xp5hk4v6kqb0sv15ciil9jyj735ylhry3qq"; }; meta.homepage = "https://github.com/goolord/alpha-nvim/"; }; </ins> aniseed = buildVimPluginFrom2Nix { pname = "aniseed"; version = "2022-05-14";
Code change:
Project description describe the project a little is a highly configurable dashboard for Neovim. It's an alternative to Metadata homepage URL: source URL: license: MIT platforms: Anything that can run Neovim, I would assume

Related discussion:
text: https://github.com/slashmili/alchemist.vim/,, https://github.com/dense-analysis/ale/,, https://github.com/vim-scripts/align/,, <ins> https://github.com/goolord/alpha-nvim/,HEAD, </ins> https://github.com/Olical/aniseed/,, https://github.com/pearofducks/ansible-vim/,, https://github.com/ckarnell/antonys-macro-repeater/,,