jiebi/CodeConvo huggingface dataset:
Code change:
A clear and concise description of what the bug is. Steps to reproduce the behavior: -p nixops ... ... it builds! error: builder for '/nix/store/48sdc9gb26pb3prykylvy644mmsma0km-python2.7-ruamel-yaml-clib-' failed with exit code 1; <!-- 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. Maintainer information:
Builds on linux thanks to .
still fails:
I think the issue is tracked in I do not understand what the state of nixops is. is an issue about NixOps 2.0 with all checkboxes ticked. Further down in the thread there is a link to a board called . So what's going on? Are the things in that board release blockers? Which version of nixops should normal users use today? The project does not seem to make it clear.
And even with that insecure package enabled, the fails with an import error.
NixOps 1 is effectively end-of-life. That issue does not include critical usability problems present in master. To quote my response to another issue: All maintenance to the NixOps core currently happens on NixOps 2 (master / pre-release), because of the project's limited resources. NixOps 1 relies on python 2.7, so maintaining it is not feasible with the NixOps project's limited resources. Please consider helping with maintenance and testing, or donate to This fund currently supports reviews and fixes on master. Donations greatly increase our ability to get things merged and work towards a functional NixOps 2 release.
Is there a current way to get oneself an overview of what's working in NixOps 2 master, and what isn't? Is it I would like to contribute testing it, but need to know: what the migration path from nixops 1 is (can I continue to use my existing state files?) whether there are dangerous unaddressed issues (will it wipe my infrastructure?) if there are key unsupported parts that nixops 1 has (Hetzner support, EC2 support, Route53 support)
Yes, this is more up to date than the previously linked issue. I'll have to refer to the issues and PRs. For the core, that's The documentation is still lacking in this regard, and some more work on the legacy state storage backend or other state storage code may need to be done, e.g. In my experience, NixOps 1 state files can be picked up by NixOps 2, but the opposite may not be true. Unlikely, but check the issues and prs of the plugins you're using. The plugins that are responsible for these parts should continue to support whatever those parts used to support, and they are available. IIRC we have two plugins for Hetzner now, one using a newer API. I have not worked on any hetzner related code.
don't you dare.
The build passes, if you permit that insecurity, now.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: { lib , buildPythonPackage , fetchPypi <del> , flake8 , pytest_4 , pytest-expect , mock </del> , six , webencodings <ins> , mock , pytest-expect , pytestCheckHook_5 </ins> }: buildPythonPackage rec {
Code change:
Launch GNOME Music 3.18 There's no artwork at all Log: System: (Flounder) Nix version: nix-env (Nix) 1.11.2

Related discussion:
text: , gmime, json_glib, avahi, tracker, itstool }: stdenv.mkDerivation rec { <del> name = "grilo-plugins-0.2.13"; </del> <ins> name = "grilo-plugins-0.2.16"; </ins> src = fetchurl { url = "mirror://gnome/sources/grilo-plugins/0.2/${name}.tar.xz"; <del> sha256 = "008jwm5ydl0k25p3d2fkcail40fj9y3qknihxb5fg941p8qlhm55"; </del> <ins> sha256 = "00sjmkzxc8w4qn4lp5yj65c4y83mwhp0zlvk11ghvpxnklgmgd40"; </ins> }; installFlags = [ "GRL_PLUGINS_DIR=$(out)/lib/grilo-0.2" ];
Code change:
Launch GNOME Music 3.18 There's no artwork at all Log: System: (Flounder) Nix version: nix-env (Nix) 1.11.2

Related discussion:
text: , libxml2, gnome3, gobjectIntrospection, libsoup }: stdenv.mkDerivation rec { <del> name = "grilo-0.2.12"; </del> <ins> name = "grilo-0.2.14"; </ins> src = fetchurl { url = "mirror://gnome/sources/grilo/0.2/${name}.tar.xz"; <del> sha256 = "11bvc7rsrjjwz8hp67p3fn8zmywrpawrcbi3vgw8b0dwa0sndd2m"; </del> <ins> sha256 = "1k8wj8f7xfaw5hxypnmwd34li3fq8h76dacach547rvsfjhjxj3r"; </ins> }; setupHook = ./setup-hook.sh;
Code change:
unbound-full cannot be built on the unstable channel error message: Steps to reproduce the behavior: build .#unbound-full It should obviously build cc Maintainer information:
This happened in the fixupPhase, maybe we should remove lines?
I've put some information on

Related discussion:
text: , withDNSTAP ? false , withTFO ? false , withRedis ? false <ins> # Avoid .lib depending on openssl.out # The build gets a little hacky, so in some cases we disable this approach. , withSlimLib ? stdenv.isLinux && !stdenv.hostPlatform.isMusl && !withDNSTAP </ins> , libnghttp2 }:
Code change:
unbound-full cannot be built on the unstable channel error message: Steps to reproduce the behavior: build .#unbound-full It should obviously build cc Maintainer information:
This happened in the fixupPhase, maybe we should remove lines?
I've put some information on

Related discussion:
text: --prefix PATH : ${lib.makeBinPath [ openssl ]} ''; <del> preFixup = lib.optionalString (stdenv.isLinux && !stdenv.hostPlatform.isMusl) # XXX: revisit </del> <ins> preFixup = lib.optionalString withSlimLib </ins> # Build libunbound again, but only against nettle instead of openssl. # This avoids gnutls.out -> unbound.lib -> openssl.out. <del> # There was some problem with this on Darwin; let's not complicate non-Linux. </del> '' configureFlags="$configureFlags --with-nettle=${nettle.dev} --with-libunbound-only" configurePhase
Code change:
Get a mac with facetimehd support and the following the laptop lid the lid back (might also need to press a key) I'm running unstable and assuming its broken on 16.03 too. System: (NixOS: , Ubuntu/Fedora: , ...) 16.09pre79453. (Flounder) Nix version: (run ) nix-env (Nix) 1.11.2 Nixpkgs version: (run ) "16.09pre79453."
It is broken since since the module is using which is obsolete and can't handle compressed modules.
Can you report if fixes this?
yes switching to kmod works (only tested facetimehd). Are there plans porting this over to 16.03?
Yeah, I assume we should port it &ndash; it doesn't seem likely to break anything and it does fix some bugs.
Oh hrm. I missed this issue conversation and put in this PR: I reckon we should backport , and
This is fixed in 16.03 and master. can you close?

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:
Get a mac with facetimehd support and the following the laptop lid the lid back (might also need to press a key) I'm running unstable and assuming its broken on 16.03 too. System: (NixOS: , Ubuntu/Fedora: , ...) 16.09pre79453. (Flounder) Nix version: (run ) nix-env (Nix) 1.11.2 Nixpkgs version: (run ) "16.09pre79453."
It is broken since since the module is using which is obsolete and can't handle compressed modules.
Can you report if fixes this?
yes switching to kmod works (only tested facetimehd). Are there plans porting this over to 16.03?
Yeah, I assume we should port it &ndash; it doesn't seem likely to break anything and it does fix some bugs.
Oh hrm. I missed this issue conversation and put in this PR: I reckon we should backport , and
This is fixed in 16.03 and master. can you close?

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:
libcanberra is not included in of thunderbird and firefox. This prevents both applications from playing gtk sounds (for instance when receiving an email on thunderbird). Steps to reproduce the behavior: any instance of firefox And in the output of strace you will see that firefox doesn't try to open the lib dir of libcanberra in the nix store. For instance on my system: libcanberra is supposed to be in the of firefox and thunderbird wrappers. AFAIU firefox and thunderbird open this library at runtime with dlopen and that's why it's not in the generated . <!-- 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. Maintainer information:
You are correct. It probably should be to the wrapper. It seems is pulled in by . Not sure what it is doing or if it is needed but adding to should address . On another note, there ought to be a tool that searches Firefox's source code for all runtime shenanigans. Also the wrapper should probably be expanded so that overriding packages into is possible.
This bug still exists. Is there any idea?

Related discussion:
text: ++ lib.optional jackSupport libjack2 ++ lib.optional smartcardSupport opensc ++ lib.optional (cfg.speechSynthesisSupport or false) speechd <del> ++ pkcs11Modules; </del> <ins> ++ pkcs11Modules ++ gtk_modules; </ins> gtk_modules = [ libcanberra-gtk3 ]; launcherName = "${applicationName}${nameSuffix}";
Code change:
Running fails with the following error: The issue is here: Before the 2.8.0 update, this line used to say So, flutter copied the cache to , which was fine. Now, however, it tries to copy the cache to , which doesn't exist, so flutter throws an error. Steps to reproduce the behavior: do any flutter project `flutter run Flutter builds the app and runs it on the device Please run and paste the result. I cannot run it because I use flakes, so it just says .
My bad, it should be fixed by
thanks!

Related discussion:
text: final Uri entryUri = _fileSystem.path.toUri(asset); result.add(_Asset( -          baseDir: _fileSystem.path.join(Cache.flutterRoot!, 'bin', 'cache', 'artifacts', 'material_fonts'), <del> +          baseDir: _fileSystem.path.join(globals.fsUtils.homeDirPath!, 'bin', 'cache', 'artifacts', 'material_fonts'), </del> <ins> +          baseDir: _fileSystem.path.join(globals.fsUtils.homeDirPath!, '.cache', 'flutter', 'artifacts', 'material_fonts'), </ins> relativeUri: Uri(path: entryUri.pathSegments.last), entryUri: entryUri, package: null,
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 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: roon-server <!-- The current version can be found easily with the same process than 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.8-850 desired version: 1.8-880 <!-- 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: , icu66 , krb5 , lib <ins> , libtasn1 </ins> , makeWrapper , stdenv , openssl }: stdenv.mkDerivation rec { pname = "roon-server"; <del> version = "1.8-850"; </del> <ins> version = "1.8-880"; </ins> src = let
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 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: roon-server <!-- The current version can be found easily with the same process than 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.8-850 desired version: 1.8-880 <!-- 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: in fetchurl { url = "http://download.roonlabs.com/builds/RoonServer_linuxx64_${urlVersion}.tar.bz2"; <del> sha256 = "sha256-NSNaL0ERYTSYn9ETjWcQiuI4hY+w/lWVOz3n9lt6O+4="; </del> <ins> sha256 = "sha256-Td3iRYGmTg8Vx9c4e4ugIIbAqhDFPax9vR2BsCIQCZA="; </ins> }; <ins> dontConfigure = true; dontBuild = true; </ins> buildInputs = [ alsa-lib freetype krb5 <ins> libtasn1 </ins> stdenv.cc.cc.lib ];
Code change:
mediathekview might be affected, the latest version 13.8.1 patched the distributed log4j version As it also updated compatibility to Java 17, and no working Java 17 distribution is in 21.11 or master atm, I'm still working on how to best address this.
See PR Full update depends on updated Java 17 , manual patching might be needed in the mean time. As it is distributed as a binary and log4j is packed into the main jar, I'm a bit stumped at the moment how to approach this.
Might work
See PR for a fix

Related discussion:
text: <del> { lib, stdenv, fetchurl, makeWrapper, jre }: </del> <ins> { lib, stdenv, fetchurl, makeWrapper, jre, zip }: </ins> stdenv.mkDerivation rec { version = "13.8.0";
Code change:
mediathekview might be affected, the latest version 13.8.1 patched the distributed log4j version As it also updated compatibility to Java 17, and no working Java 17 distribution is in 21.11 or master atm, I'm still working on how to best address this.
See PR Full update depends on updated Java 17 , manual patching might be needed in the mean time. As it is distributed as a binary and log4j is packed into the main jar, I'm a bit stumped at the moment how to approach this.
Might work
See PR for a fix

Related discussion:
text: sha256 = "0zfkwz5psv7m0881ykgqrxwjhadg39c55aj2wpy7m1jdara86c5q"; }; <del> nativeBuildInputs = [ makeWrapper ]; </del> <ins> nativeBuildInputs = [ makeWrapper zip ]; </ins> installPhase = '' runHook preInstall mkdir -p $out/{bin,lib} <ins> # log4j mitigation, see https://logging.apache.org/log4j/2.x/security.html zip -d MediathekView.jar org/apache/logging/log4j/core/lookup/JndiLookup.class </ins> install -m644 MediathekView.jar $out/lib makeWrapper ${jre}/bin/java $out/bin/mediathek
Code change:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- 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.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: }: buildPythonPackage rec { <del> version = "1.6.0"; </del> <ins> version = "1.6.1"; </ins> pname = "strictyaml"; disabled = isPy27; src = fetchPypi { inherit pname version; <del> sha256 = "73fa9769214a310486d7916453a09bd38b07d28a9dcbdf27719183c1d7d949f6"; </del> <ins> sha256 = "688be16ee5d1a2f94aa4abdc6d881e8e254d173d724ac88725955fe66bdb63d4"; </ins> }; postPatch = ''
Code change:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- 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.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: buildPythonPackage rec { pname = "tatsu"; <del> version = "5.6.1"; </del> <ins> version = "5.7.1"; </ins> src = fetchFromGitHub { owner = "neogeny"; repo = "TatSu"; rev = "v${version}"; <del> sha256 = "149ra1lwax5m1svlv4dwjfqw00lc5vwyfj6zw2v0ammmfm1b94x9"; </del> <ins> sha256 = "12ljff6l29q92625pgsg4f7xf4dz6iz1c3zdkzz188s4lnwpy8b8"; </ins> }; disabled = pythonOlder "3.8";
Code change:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- 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.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: buildPythonPackage rec { pname = "terminaltables"; <del> version = "3.1.0"; </del> <ins> version = "3.1.7"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "f3eb0eb92e3833972ac36796293ca0906e998dc3be91fbe1f8615b331b853b81"; </del> <ins> sha256 = "5dab2f33927c0a020b8011c81b92830ff9fd4ba701657da5d7bfdc41048360a6"; </ins> }; meta = with lib; {
Code change:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- 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.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: buildPythonPackage rec { pname = "textacy"; <del> version = "0.11.0"; </del> <ins> version = "0.12.0"; </ins> disabled = pythonOlder "3.7"; src = fetchPypi { inherit pname version; <del> sha256 = "sha256-d/tyTCewoERA15iBv4H2LORFzgco15fnnN1sneeGuF4="; </del> <ins> sha256 = "2c92bdd6b47305447b64e4cb6cc43c11675f021f910a8074bc8149dbf5325e5b"; </ins> }; propagatedBuildInputs = [
Code change:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- 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.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: buildPythonApplication rec { pname = "trytond"; <del> version = "6.2.1"; </del> <ins> version = "6.2.2"; </ins> format = "setuptools"; disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; <del> sha256 = "418f16c45b7130555447af901639b92bb188d39f46ce7fe4dfcd941c5959ed7e"; </del> <ins> sha256 = "9494016dd8b4da5a06dccdd1afbd918248d42da9f2c19b1eb8958052c747e193"; </ins> }; # Tells the tests which database to use
Code change:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- 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.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: buildPythonPackage rec { pname = "types-protobuf"; <del> version = "3.18.1"; </del> <ins> version = "3.18.2"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "6696bf3cabc51dcc076e8de025c405dbdea7488c5268c2febd14527dac82c233"; </del> <ins> sha256 = "ca21dedfe7759acbeb0cd8f5c72a74ff3c409ae0c07bc1d94eff5123ac0fa23c"; </ins> }; propagatedBuildInputs = [ types-futures ];
Code change:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- 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.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: buildPythonPackage rec { pname = "websocket-client"; <del> version = "1.2.1"; </del> <ins> version = "1.2.2"; </ins> disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; <del> sha256 = "8dfb715d8a992f5712fff8c843adae94e22b22a99b2c5e6b0ec4a1a981cc4e0d"; </del> <ins> sha256 = "21861f8645eb5725d1becfe86d7e7ae1a31d98b72556f9d44fcc5100976353cf"; </ins> }; propagatedBuildInputs = [