jiebi/CodeConvo huggingface dataset:
Code change:
Describe the bug Trying to run a nautilus-python extension (syncstate-) fails with ImportError: could not import gobject (error was: ModuleNotFoundError("No module named 'gi'")) To Reproduce gnome3 and install nextcloud-client nautilus from terminal with something like Expected behavior python should find gi. Additional context I think it is part of pygobject3 which is in buildInputs therefore I think it is a problem of a wrong NIXPYTHONPATH Notify maintainers Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
I am not sure if it ever worked. The shared module links against pygobject but that still does not have to mean the gi module will be available on Python side. Maybe we need something like the following: At least until we have .
Yes this works, thank you!
hmmm I just tried with the new nautilus-python, but the nautilus python extensions still fail due to missing gi. Is there a reason that you tried to load gi in nautilus-python and not add the prefix arg as in your comment?
Did you make sure is updated? It worked for me with gsconnect extension. I chose that method because pygobject is really nautilus-python dependency, not nautilus one.
nevermind it works now (also with nextcloud), I forgot the in the overlay where I overwrote the package from master. Thanks for fixing it!

Related discussion:
text: <ins> diff --git a/src/nautilus-python.c b/src/nautilus-python.c index 843e3c6..466a513 100644 --- a/src/nautilus-python.c +++ b/src/nautilus-python.c @@ -184,6 +184,9 @@ nautilus_python_init_python (void) { return FALSE; } +    debug("Add PyGObject to path"); +    PyRun_SimpleString("import site;import functools; functools.reduce(lambda k, p: site.addsitedir(p, k), [@pythonPaths@], site._init_pathinfo())"); + /* import gobject */ debug("init_pygobject"); if (!np_init_pygobject()) { </ins>
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: ghc <!-- 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: desired version: <!-- 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.
Today I tried to install , but it failed at downloading : complained about hash mismatch. It seems like URL has changed.
I used the following overlay as a workaround:
Should work with .

Related discussion:
text: # https://downloads.haskell.org/~ghc/8.10.2/ src = fetchurl ({ i686-linux = { <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-i386-deb9-linux.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-i386-deb9-linux.tar.xz"; </ins> sha256 = "0bvwisl4w0z5z8z0da10m9sv0mhm9na2qm43qxr8zl23mn32mblx"; }; x86_64-linux = { <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-x86_64-deb10-linux.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-x86_64-deb10-linux.tar.xz"; </ins> sha256 = "0chnzy9j23b2wa8clx5arwz8wnjfxyjmz9qkj548z14cqf13slcl"; }; armv7l-linux = { <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-armv7-deb10-linux.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-armv7-deb10-linux.tar.xz"; </ins> sha256 = "1j41cq5d3rmlgz7hzw8f908fs79gc5mn3q5wz277lk8zdf19g75v"; }; aarch64-linux = { <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-aarch64-deb10-linux.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-aarch64-deb10-linux.tar.xz"; </ins> sha256 = "14smwl3741ixnbgi0l51a7kh7xjkiannfqx15b72svky0y4l3wjw"; }; x86_64-darwin = { <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-x86_64-apple-darwin.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-x86_64-apple-darwin.tar.xz"; </ins> sha256 = "1hngyq14l4f950hzhh2d204ca2gfc98pc9xdasxihzqd1jq75dzd"; }; }.${stdenv.hostPlatform.system}
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: ghc <!-- 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: desired version: <!-- 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.
Today I tried to install , but it failed at downloading : complained about hash mismatch. It seems like URL has changed.
I used the following overlay as a workaround:
Should work with .

Related discussion:
text: else "${lib.getLib glibc}/lib/ld-linux*"; <ins> downloadsUrl = "https://downloads.haskell.org/ghc"; </ins> in stdenv.mkDerivation rec {
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: ghc <!-- 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: desired version: <!-- 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.
Today I tried to install , but it failed at downloading : complained about hash mismatch. It seems like URL has changed.
I used the following overlay as a workaround:
Should work with .

Related discussion:
text: src = fetchurl ({ i686-linux = { # Don't use the Fedora27 build (as below) because there isn't one! <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-i386-deb9-linux.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-i386-deb9-linux.tar.xz"; </ins> sha256 = "1p2h29qghql19ajk755xa0yxkn85slbds8m9n5196ris743vkp8w"; }; x86_64-linux = { # This is the Fedora build because it links against ncurses6 where the # deb9 one links against ncurses5, see here # https://github.com/NixOS/nixpkgs/issues/85924 for a discussion <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-x86_64-fedora27-linux.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-x86_64-fedora27-linux.tar.xz"; </ins> sha256 = "18dlqm5d028fqh6ghzn7pgjspr5smw030jjzl3kq6q1kmwzbay6g"; }; aarch64-linux = { <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-aarch64-ubuntu18.04-linux.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-aarch64-ubuntu18.04-linux.tar.xz"; </ins> sha256 = "11n7l2a36i5vxzzp85la2555q4m34l747g0pnmd81cp46y85hlhq"; }; x86_64-darwin = { <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-x86_64-apple-darwin.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-x86_64-apple-darwin.tar.xz"; </ins> sha256 = "0s9188vhhgf23q3rjarwhbr524z6h2qga5xaaa2pma03sfqvvhfz"; }; }.${stdenv.hostPlatform.system}
Code change:
nixosTests.blockbook-frontend fails to build Discovered in Refs Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Maintainer information:
cc
Tests are "fine". It's the main that's causing the issues (failing to build) and it was not working for some time now (as I've discovered also ). I did some initial debugging and broke the . I've notified upstream but I guess there's little I can do about it so it either gets fixed or we should remove the package altogether.
Hm, I suggest we mark blockbook as broken for the time being:

Related discussion:
text: license = licenses.agpl3; maintainers = with maintainers; [ mmahut _1000101 ]; platforms = platforms.unix; <ins> # go dependency tecbot/gorocksdb requires rocksdb 5.x but nixpkgs has only rocksdb 6.x # issue in upstream can be tracked here: https://github.com/trezor/blockbook/issues/617 broken = true; </ins> }; }
Code change:
Describe the bug nextcloud default nginx config did not include the ` config see: but expires is set in Expected behavior no expires, the cache option causes problems with the usage of Deck

Related discussion:
text: }; extraConfig = '' index index.php index.html /index.php$request_uri; <del> expires 1m; </del> add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none;
Code change:
Describe the bug The phosh lockscreen will accept any pin. To Reproduce Steps to reproduce the behavior: phosh screen with 1 even if it isn't your pin! Expected behavior Probably use the numeric password of the user Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Solution The PAM configuration seems to be at fault. I can't PAM my way out of a paper bag, but I tried one attempt: Why ? Here's why: That doesn't explain the issue. Only a plausible fix. With this, only the user password is accepted. We should get someone who understand PAM to look at this. Metadata Ran on top of . Maintainer information:
Uh, so the problem is that does not exist, so there are no requirements enforced? Or what does our pam file for phosh look like? The better approach would likely be to add here:
Sorry, I probably misexplained a bit here: we're not using the manjaro pam bit at all. So I suspect those are not good at all. When using the manjaro bit verbatim, you just can't unlock! I guess adding to that list you linked to could do it too? If the other snippet is removed.
Ouch, that pam file is not testing for anything meaningful, so it shouldn't come as a surprise. Login works if you are not root. pamnologin is a PAM module that prevents users from logging into the system when /etc/nologin exists is designed to succeed or fail authentication based on characteristics of the account belonging to the user being authenticated. pamsecuretty is a PAM module that allows root logins only if the user is logging in on a "secure" tty, (Quoting from their individual manpages) Because we have no pam.d file.

Related discussion:
text: programs.feedbackd.enable = true; <del> # https://source.puri.sm/Librem5/phosh/-/issues/303 security.pam.services.phosh = { text = '' auth    requisite       pam_nologin.so auth    required        pam_succeed_if.so user != root quiet_success auth    required        pam_securetty.so auth    requisite       pam_nologin.so ''; }; </del> <ins> security.pam.services.phosh = {}; </ins> services.gnome.core-shell.enable = true; services.gnome.core-os-services.enable = true;
Code change:
Describe the bug json-glib seems to be a new transitive dependency of tracker/gtk, which the Paradox launcher needs. Somehow it isn't being pulled into the Steam container. To Reproduce Steps to reproduce the behavior: Steam a Paradox game (eg. Stellaris) to start the game Expected behavior Instead of the launcher working as usual, it doesn't launch at all. Launching it directly yields the following error: Additional context Adding json-glib to steam's fhs wrapper libraries is sufficient to start the launcher, but should it be propagated by gtk implicitly? 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 Please run and paste the result. Maintainer information:
which game? I tried eu4 and CK3 and both launch fine
Stellaris. Funny that it seems to work with the others, I suppose it could be something specific to my system?
Unlikely, steam games run in a bubblewrap sandbox, so your host system doesn't matter much.

Related discussion:
text: gst_all_1.gstreamer gst_all_1.gst-plugins-ugly gst_all_1.gst-plugins-base <ins> json-glib # paradox launcher (Stellaris) </ins> libdrm libxkbcommon # paradox launcher mono
Code change:
It used to be possible to build (it is possible on 20.09), but these days it fails with: I’ll try to bisect it…
Bisecting points to by Nathan, do you have a hunch?
Cargoculting what I saw in the GHC code, trying this right now:
Seems to work, fix in
There appear to be multiple linker bugs affecting at least Rust and GHC with Musl . Both bfd or gold had issues, gold seems a little worse. I would suggest trying lld, it may fix it.
lld with gcc is currently not supported and I think last time I tried we can't build OCaml and all its dependencies with clang+lld fully yet…
The second commit of ("match leading/trailing arguments") should fix this
That's great news!
Fixed by

Related discussion:
text: nativeBuildInputs = [ pkgconfig gettext perl python ]; <del> propagatedBuildInputs = [ pcre zlib libffi ] ++ libiconvOrEmpty ++ libintlOrEmpty; </del> <ins> propagatedBuildInputs = [ pcre zlib libffi ] ++ optional (!stdenv.isDarwin) libiconvOrEmpty ++ libintlOrEmpty; </ins> configureFlags = optional stdenv.isDarwin "--disable-compile-warnings"
Code change:
It used to be possible to build (it is possible on 20.09), but these days it fails with: I’ll try to bisect it…
Bisecting points to by Nathan, do you have a hunch?
Cargoculting what I saw in the GHC code, trying this right now:
Seems to work, fix in
There appear to be multiple linker bugs affecting at least Rust and GHC with Musl . Both bfd or gold had issues, gold seems a little worse. I would suggest trying lld, it may fix it.
lld with gcc is currently not supported and I think last time I tried we can't build OCaml and all its dependencies with clang+lld fully yet…
The second commit of ("match leading/trailing arguments") should fix this
That's great news!
Fixed by

Related discussion:
text: propagatedBuildInputs = with xlibs; with stdenv.lib; [ glib cairo pango gdk_pixbuf atk ] <del> ++ optionals stdenv.isLinux [ libXrandr libXrender libXcomposite libXi libXcursor ] ++ optional stdenv.isDarwin x11 </del> <ins> ++ optionals (stdenv.isLinux || stdenv.isDarwin) [ libXrandr libXrender libXcomposite libXi libXcursor ] ++ optionals stdenv.isDarwin [ x11 libXdamage ] </ins> ++ libintlOrEmpty ++ optional xineramaSupport libXinerama ++ optionals cupsSupport [ cups ]; <del> configureFlags = "--with-xinput=yes"; </del> <ins> configureFlags = if stdenv.isDarwin then "--disable-glibtest --disable-introspection --disable-visibility" else "--with-xinput=yes"; </ins> postInstall = "rm -rf $out/share/gtk-doc";
Code change:
It used to be possible to build (it is possible on 20.09), but these days it fails with: I’ll try to bisect it…
Bisecting points to by Nathan, do you have a hunch?
Cargoculting what I saw in the GHC code, trying this right now:
Seems to work, fix in
There appear to be multiple linker bugs affecting at least Rust and GHC with Musl . Both bfd or gold had issues, gold seems a little worse. I would suggest trying lld, it may fix it.
lld with gcc is currently not supported and I think last time I tried we can't build OCaml and all its dependencies with clang+lld fully yet…
The second commit of ("match leading/trailing arguments") should fix this
That's great news!
Fixed by

Related discussion:
text: { stdenv, fetchurl, pkgconfig, glib, freetype, cairo, libintlOrEmpty , icu, graphite2 , withIcu ? false # recommended by upstream as default, but most don't needed and it's big <del> , withGraphite2 ? true # it is small and major distros do include it </del> <ins> , withGraphite2 ? !stdenv.isDarwin # it is small and major distros do include it </ins> }: # TODO: split non-icu and icu lib into different outputs?
Code change:
It used to be possible to build (it is possible on 20.09), but these days it fails with: I’ll try to bisect it…
Bisecting points to by Nathan, do you have a hunch?
Cargoculting what I saw in the GHC code, trying this right now:
Seems to work, fix in
There appear to be multiple linker bugs affecting at least Rust and GHC with Musl . Both bfd or gold had issues, gold seems a little worse. I would suggest trying lld, it may fix it.
lld with gcc is currently not supported and I think last time I tried we can't build OCaml and all its dependencies with clang+lld fully yet…
The second commit of ("match leading/trailing arguments") should fix this
That's great news!
Fixed by

Related discussion:
text: enableParallelBuilding = true; <del> doCheck = true; </del> <ins> # jww (2014-05-05): The tests currently fail on Darwin: # # ERROR:testiter.c:139:iter_char_test: assertion failed: (extents.width == x1 - x0) # .../bin/sh: line 5: 14823 Abort trap: 6 srcdir=. PANGO_RC_FILE=./pangorc ${dir}$tst # FAIL: testiter doCheck = !stdenv.isDarwin; </ins> postInstall = "rm -rf $out/share/gtk-doc"; meta = {
Code change:
It used to be possible to build (it is possible on 20.09), but these days it fails with: I’ll try to bisect it…
Bisecting points to by Nathan, do you have a hunch?
Cargoculting what I saw in the GHC code, trying this right now:
Seems to work, fix in
There appear to be multiple linker bugs affecting at least Rust and GHC with Musl . Both bfd or gold had issues, gold seems a little worse. I would suggest trying lld, it may fix it.
lld with gcc is currently not supported and I think last time I tried we can't build OCaml and all its dependencies with clang+lld fully yet…
The second commit of ("match leading/trailing arguments") should fix this
That's great news!
Fixed by

Related discussion:
text: libXmu libXext xextproto libSM libICE; ghostscript = ghostscriptX; harfbuzz = harfbuzz.override { <del> withIcu = true; withGraphite2 = true; </del> <ins> withIcu = true; withGraphite2 = !stdenv.isDarwin; </ins> }; };
Code change:
, CVSSv3=7.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
09 is still vulnerable
NixOS 20.09 is EOL, so this issue isn't actionable anymore.

Related discussion:
text: buildCommand = "sed s/dot_root/agroot/g ${raw_patch} > $out"; }; # 2.42 has the patch included <del> patches = optional (lib.versionOlder version "2.42") patchToUse; </del> <ins> patches = optional (lib.versionOlder version "2.42") patchToUse ++ optionals (lib.versionOlder version "2.46.0") [ (fetchpatch { name = "CVE-2020-18032.patch"; url = "https://gitlab.com/graphviz/graphviz/-/commit/784411ca3655c80da0f6025ab20634b2a6ff696b.patch"; sha256 = "1nkw9ism8lkfvxsp5fh95i2l5s5cbjsidbb3g1kjfv10rxkyb41m"; }) ]; </ins> in stdenv.mkDerivation {
Code change:
, CVSSv3=7.5 (nixos-20.09, nixos-unstable) CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc

Related discussion:
text: in { openvpn_24 = generic { <del> version = "2.4.9"; sha256 = "1qpbllwlha7cffsd5dlddb8rl22g9rar5zflkz1wrcllhvfkl7v4"; </del> <ins> version = "2.4.11"; sha256 = "06s4m0xvixjhd3azrzbsf4j86kah4xwr2jp6cmcpc7db33rfyyg5"; </ins> }; openvpn = generic { <del> version = "2.5.0"; sha256 = "sha256-AppCbkTWVstOEYkxnJX+b8mGQkdyT1WZ2Z35xMNHj70="; </del> <ins> version = "2.5.2"; sha256 = "sha256-sSdDg2kB82Xvr4KrJJOWfhshwh60POmo2hACoXycHcg="; </ins> }; }
Code change:
Describe the bug fails to build on master/release-21.05. The build failure ( is not found anymore by cmake) appeared with the update of from 2.9.10 to 2.9.12. Addressing CC

Related discussion:
text: <ins> diff --color -ur a/CMakeLists.txt b/CMakeLists.txt --- a/CMakeLists.txt	2021-05-30 13:46:22.256040282 +0200 +++ b/CMakeLists.txt	2021-05-30 14:15:42.530181216 +0200 @@ -333,7 +333,7 @@ # So, try first to find the CMake module provided by libxml2 package, then fallback # on the CMake's FindLibXml2.cmake module (which can lack some definition, especially # in static build case). -find_package(LibXml2 QUIET NO_MODULE) +find_package(LibXml2 QUIET MODULE) if(DEFINED LIBXML2_VERSION_STRING) set(LIBXML2_FOUND ON) set(LIBXML2_INCLUDE_DIR ${LIBXML2_INCLUDE_DIRS}) Seulement dans b: good.patch </ins>
Code change:
Describe the bug fails to build on master/release-21.05. The build failure ( is not found anymore by cmake) appeared with the update of from 2.9.10 to 2.9.12. Addressing CC

Related discussion:
text: sha256 = "0psw67mzysdb8fkh8xpcwicm7z94k8plkcc8ymxyvl6inshq0mc7"; }; <ins> # Revert after https://github.com/NixOS/nixpkgs/issues/125008 is # fixed properly patches = [ ./cmake-fix-libxml2-find-package.patch ]; </ins> nativeBuildInputs = [ cmake flex
Code change:
Describe the bug The rhdf5 library does not work on latest release. To Reproduce Expected behavior A shell with R and rhdf5. Additional context Instead I get: Notify maintainers Metadata Maintainer information:
"6.topic: rust" should be removed, this is an R package, not Rust.
This was fixed in

Related discussion:
text: Rglpk = [ pkgs.glpk ]; RGtk2 = [ pkgs.gtk2.dev ]; rhdf5 = [ pkgs.zlib ]; <del> Rhdf5lib = [ pkgs.zlib ]; </del> <ins> Rhdf5lib = [ pkgs.zlib.dev ]; </ins> Rhpc = [ pkgs.zlib pkgs.bzip2.dev pkgs.icu pkgs.xz.dev pkgs.mpi pkgs.pcre.dev ]; Rhtslib = [ pkgs.zlib.dev pkgs.automake pkgs.autoconf pkgs.bzip2.dev pkgs.xz.dev pkgs.curl.dev ]; rjags = [ pkgs.jags ];
Code change:
Describe the bug The rhdf5 library does not work on latest release. To Reproduce Expected behavior A shell with R and rhdf5. Additional context Instead I get: Notify maintainers Metadata Maintainer information:
"6.topic: rust" should be removed, this is an R package, not Rust.
This was fixed in

Related discussion:
text: index e2d292e..b13c0db 100755 --- a/configure +++ b/configure <del> @@ -2880,6 +2880,7 @@ $MAKE </del> <ins> @@ -3874,6 +3874,7 @@ </ins> echo "building the hdf5 library..."; cd ../; <del> ## we add the '-w' flag to suppress all the warnings hdf5 prints </del> +sed -i 's#/bin/mv#mv#' configure <del> ./configure --with-pic --enable-shared=no --enable-cxx  --with-szlib  CXX="${CXX}" CXFLAGS="${CXXFLAGS} -w"  </del> <ins> ./configure --with-pic --enable-shared=no --enable-cxx --enable-hl  --with-szlib=${SZIP_HOME} --with-zlib=${ZLIB_HOME}  ${WITH_S3_VFD}  </ins>