jiebi/CodeConvo huggingface dataset:
Change:
sha256 = "161050sx3sdxqcpjkjcpf6wl4kx0jydihga7mcvrj9c2f8ly0g07"; }; <ins> patches = [ # Make PyGObject’s gi library available. (substituteAll { src = ./fix-paths.patch; pythonPaths = lib.concatMapStringsSep ", " (pkg: "'${pkg}/${python3.sitePackages}'") [ python3.pkgs.pygobject3 ]; }) ]; </ins> nativeBuildInputs = [ pkg-config which

Discussion:
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!
Change:
mkdir -p $out/bin ln -s $out/share/postman/postman $out/bin/postman <ins> source "${makeWrapper}/nix-support/setup-hook" wrapProgram $out/bin/${pname}  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--enable-features=UseOzonePlatform --ozone-platform=wayland}}" </ins> mkdir -p $out/share/icons/hicolor/128x128/apps ln -s $out/share/postman/resources/app/assets/icon.png $out/share/icons/postman.png ln -s $out/share/postman/resources/app/assets/icon.png $out/share/icons/hicolor/128x128/apps/postman.png

Discussion:
A few electron applications do not use environment variable to change settings. This causes a black screen when using these packages on wayland. Packages I have found not to work: postman beekeeper-studio This was made known to me by on Discord. Steps to reproduce the behavior: Black screen. ! ! A temporary work around is to run the application with the flag. I will work on this myself. <!-- 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.
If any other packages are exhibiting this behavior please let me know on this issue.
Package also seems to not respect the env
Can confirm, I'll create a new pr.
Sorry for taking so long, stuff happened
Ferdium also does not respect the env (and I assume Ferdi and Franz by looking at their sources).
For some reason the following is not working: But this is: I do have both NIXOSOZONEWL and WAYLANDDISPLAY set.
Change:
<del> diff --git a/src/copy.c b/src/copy.c index cb9018f93..2a4ccc061 100644 --- a/src/copy.c +++ b/src/copy.c @@ -502,7 +502,7 @@ write_zeros (int fd, off_t n_bytes) return true; } -#ifdef SEEK_HOLE +#if 0 /* Perform an efficient extent copy, if possible.  This avoids the overhead of detecting holes in hole-introducing/preserving copy, and thus makes copying sparse files much more efficient. @@ -1095,7 +1095,7 @@ infer_scantype (int fd, struct stat const *sb, && ST_NBLOCKS (*sb) < sb->st_size / ST_NBLOCKSIZE)) return PLAIN_SCANTYPE; -#ifdef SEEK_HOLE +#if 0 scan_inference->ext_start = lseek (fd, 0, SEEK_DATA); if (0 <= scan_inference->ext_start) return LSEEK_SCANTYPE; @@ -1377,7 +1377,7 @@ copy_reg (char const *src_name, char const *dst_name, off_t n_read; bool wrote_hole_at_eof = false; if (! ( -#ifdef SEEK_HOLE +#if 0 scantype == LSEEK_SCANTYPE ? lseek_copy (source_desc, dest_desc, buf, buf_size, hole_size, scan_inference.ext_start, src_open_sb.st_size, diff --git a/tests/seek-data-capable b/tests/seek-data-capable index cc6372214..6e7a9ec1e 100644 --- a/tests/seek-data-capable +++ b/tests/seek-data-capable @@ -1,5 +1,7 @@ import sys, os, errno, platform +sys.exit(1) + # Pass an _empty_ file if len(sys.argv) != 2: sys.exit(1) </del>

Discussion:
<!-- 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: coreutils <!-- 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: 9.0 desired version: 9.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.
I'm already on it :) might take some while before I do the pr because I want to build stdenv first
Change:
, cmark , file , glibcLocales <ins> , six , typing </ins> }: rec {

Discussion:
fails with the error message: Steps to reproduce the behavior: install bats <details<summarynix profile install nixpkgs#bats --show-trace</summary</detailsupgrading bats fails with the same error (assuming one had installed it before) n.a. Please run and paste the result.
This will be fixed by
Change:
## Backward Incompatibilities {#sec-release-24.11-incompatibilities} <del> - Create the first release note entry in this section! </del> <ins> - `nvimpager` was updated to version 0.13.0, which changes the order of user and nvimpager settings: user commands in `-c` and `--cmd` now override the respective default settings because they are executed later. </ins> ## Other Notable Changes {#sec-release-24.11-notable-changes}

Discussion:
hydra went from to as per on a . Steps to reproduce the behavior: to nvimpager <details<summarytest failing on this update:</summary</details
To my knowledge the actual functionality of nvimpager is not affected but the default colorscheme in neovim changed and my test depend on it. So a quickfix might be if that is acceptable.
this will be fixed by .
The neovim update has been reverted in . Closing.
Change:
meta = with lib; { description = "oneAPI Deep Neural Network Library (oneDNN)"; <del> homepage = "https://01.org/dnnl"; </del> <ins> homepage = "https://01.org/oneDNN"; </ins> changelog = "https://github.com/oneapi-src/oneDNN/releases/tag/v${version}"; license = licenses.asl20; <del> platforms = [ "aarch64-linux" "x86_64-linux" ]; </del> <ins> platforms = platforms.all; </ins> maintainers = with maintainers; [ alexarice bhipple ]; }; }

Discussion:
Describe the bug oneDNN is a dependency of pytorch. Today, oneDNN's are all linux-based but oneDNN actually appears to compile fine on ; its tests just all immediately fail because of RPATH problems. To Reproduce Expected behavior I expect oneDNN to build and check successfully. Additional context I think that this problem may be able to be fixed by adding in on Darwin, much like is currently set and exported. Note, for even more detail/context on CMake's support for controlling RPATH on macOS, please see Notify maintainers Metadata (Note, I am actually testing this using nix flakes, with this ) Maintainer information:
Change:
boot.initrd.availableKernelModules = mkIf inInitrd [ "xfs" "crc32c" ]; <del> boot.initrd.extraUtilsCommands = mkIf (inInitrd && !boot.initrd.systemd.enable) </del> <ins> boot.initrd.extraUtilsCommands = mkIf (inInitrd && !config.boot.initrd.systemd.enable) </ins> '' copy_bin_and_libs ${pkgs.xfsprogs.bin}/bin/fsck.xfs copy_bin_and_libs ${pkgs.xfsprogs.bin}/bin/xfs_repair ''; # Trick just to set 'sh' after the extraUtils nuke-refs. <del> boot.initrd.extraUtilsCommandsTest = mkIf (inInitrd && !boot.initrd.systemd.enable) </del> <ins> boot.initrd.extraUtilsCommandsTest = mkIf (inInitrd && !config.boot.initrd.systemd.enable) </ins> '' sed -i -e 's,^#!.*,#!'$out/bin/sh, $out/bin/fsck.xfs '';

Discussion:
Currently blocking nixpkgs-unstable-small To reproduce: check out nixpkgs and (haven't tested myself yet)
looks like this was introduced in / and should be fixed with
Change:
# Preload extensions by moving into the runtime instead of storing under the # user's profile directory. <del> mkdir -p "$TBB_IN_STORE/browser/extensions" </del> <ins> # See https://support.mozilla.org/en-US/kb/deploying-firefox-with-extensions mkdir -p "$TBB_IN_STORE/distribution/extensions" </ins> mv "$TBB_IN_STORE/TorBrowser/Data/Browser/profile.default/extensions/"*  <del> "$TBB_IN_STORE/browser/extensions" </del> <ins> "$TBB_IN_STORE/distribution/extensions" </ins> # Hard-code paths to geoip data files.  TBB resolves the geoip files # relative to torrc-defaults_path but if we do not hard-code them

Discussion:
Describe the bug In Tor Browser, all add-ons, including HTTPS Everywhere and NoScript are disabled when you start up the browser. To Reproduce Steps to reproduce the behavior: you have Tor Browser 9.0.6 (from 20.03 or unstable). -click on the starting page. that the "NoScript" option is missing. Expected behavior All add-ons should be enabled on startup. Additional context This appears to be a regression since 9.0.5 introduced in Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
After deleting and re-starting Tor Browser, this problem seems to have gone away. I'm not sure what caused it.
It seems like switching between Tor Browser versions causes it, for instance switching from to . After deleting the Tor Browser directory once, the issue is solved until you switch again,
This happens to me even after simply quitting Tor Browser and starting again, no upgrade or change in-between, although it's not 100% reproducible - I haven't yet figured out what are the exact conditions that trigger this. It's peculiar because NoScript is missing from the UI, although it shows as enabled in about:addons. pinging the maintainers:
With the upgrade to Tor Browser 10.0.2, NoScript is missing 100% of the time, the Hightest Security Level doesn't disable javascript. I wouldn't consider using Tor Browser in this state - it's too different from its normal behavior.
It needs to be marked broken until this is resolved, imo.
potentially related upstream issue: edit: actually its probably not related What worked for me is manually copying the extension from the nix store to the profile directory: maybe this can be to in derivation? The tor-browser 10. is based on a new release of firefox, right? Then this may be because firefox stopped sideloading extensions from the installation directory (, ). Another option may be to use
I have a fix for the noscript issue, feel free to check it out, and see if it works for you. But the HTTPS Everywhere addon is loaded via a different mechanism I think? At least on my system it used to work even with the 10. version before this fix.

And do we have a channel to notify users about the fact that they potentially used a broken version of the tor-browser since (Sep 23)? This is rather critical software..
Change:
}; constituents = accumulateDerivations [ # haskell specific tests <del> # # TODO: The writers test appears to be failing on darwin for unknown # reasons.  See https://github.com/NixOS/nixpkgs/pull/129606#issuecomment-881307871. (lib.recursiveUpdate jobs.tests.haskell { writers.x86_64-darwin = null; }) </del> <ins> jobs.tests.haskell </ins> # important top-level packages jobs.cabal-install jobs.cabal2nix

Discussion:
shows: I suspected code signing at first, but this is and thus shouldn't be an issue. In the Nix on macOS channel on Matrix, someone suggested it may be a malformed Mach-O binary, Is there maybe something happening in by default we are missing here in the writer derivation? I'd appreciate help from here since I can't figure this out.
Can confirm. Note: used for that.
I can confirm.
I'm getting the following error message when running Which means
What architecture and macOS version is that?
The problem is that writers use , which uses , which doesn't use the phases so signing doesn't happen.
The problem is unrelated to signing, but I do get the impression that we are missing some darwin specific fixupPhase hook.
Darwin hydra reports now:
Change:
}; libreoffice = if stdenv.isDarwin <del> then callPackage ../applications/office/libreoffice/darwin.nix {} </del> <ins> then callPackage ../applications/office/libreoffice/darwin { } </ins> else hiPrio libreoffice-still; libreoffice-unwrapped = (hiPrio libreoffice-still).libreoffice;

Discussion:
Apparently the DMG download is 404'ing - see below. Perhaps a different mirror should be used:
Apparently they remove older versions. Maintainer:
Maybe we can use to avoid 404's.
Good input. I'll update the version and have a look at it tomorrow.
is 404'ing again: . Should we re-open this issue?
I can't see version 7.2.5 in any supported nixpkgs branch anymore. If you're using an old commit, you'll be getting old bugs, of course.
Change:
buildPythonPackage rec { pname = "sip"; <del> version = "6.7.1"; </del> <ins> version = "6.7.4"; </ins> src = fetchPypi { pname = "sip"; inherit version; <del> sha256 = "sha256-KBcP34gPk3Am/If6qcF3sGLDU8XRaeoyQrB4AmFN3Qw="; </del> <ins> sha256 = "sha256-nb+KDnyNdtFkLi/dP1PmpSL3wwmA5Sd2PEV2DCUFz78="; </ins> }; propagatedBuildInputs = [ packaging ply toml ];

Discussion:
Steps to reproduce the behavior: (or, more specifically, ): see This is on , but currently () has has the same problem (). Result of : system: host os: multi-user?: sandbox: version: channels(root): channels(das-g): nixpkgs:
(Edited description after trying to build from , where the same problem occurs.)
Reverting (python-modules/sip: 6.6.2 -6.7.1) and (python-modules/pyqt-builder: 1.13.0 -1.14.0) (both parts of PR ) would fix this, but would probably break other stuff, wouldn't it? in suggests to rather bump python-modules/sip further to 6.9.4. Either would cause 261 rebuilds. what do you (as new maintainer of python-modules/sip, author of PR and as one of the NixOS release-engineers) advise? It'd be really nice to have working QGIS versions in the NixOS 22.11 release.
I defer to whatever is better for the python ecosystem! For QGIS's part, Qt6 is irrelevant -- it doesn't even build fully using it at the moment.
I would suggest to bump sip, since that is something we will have to do eventually. We should fall back on reverting the other two commits only if that doesn't work out.
PR for bumping :
Change:
<del> { lib, stdenv, rustPlatform, fetchurl, pkg-config, ncurses, openssl, Security }: </del> <ins> { lib, stdenv, rustPlatform, fetchFromSourcehut, pkg-config, ncurses, openssl, Security }: </ins> rustPlatform.buildRustPackage rec { pname = "asuka"; version = "0.8.1"; <del> src = fetchurl { url = "https://git.sr.ht/~julienxx/${pname}/archive/${version}.tar.gz"; sha256 = "07i80qmdpwfdgwrk1gzs10wln91v23qjrsk0x134xf5mjnakxc06"; </del> <ins> src = fetchFromSourcehut { owner = "~julienxx"; repo = pname; rev = version; sha256 = "1y8v4qc5dng3v9k0bky1xlf3qi9pk2vdsi29lff4ha5310467f0k"; </ins> }; cargoSha256 = "0p0x4ch04kydg76bfal5zqzr9hvn5268wf3k2v9h7g8r4y8xqlhw";

Discussion:
Describe the bug Sources from archives from fail to download with hash mismatches. To Reproduce Expected behavior The hash should match and the source should download. Additional context It sounds like , causing changes to all generated archives (to come in-line with GNU gzip). I've determined some packages which this affects (listed in "Maintainer information") by . I'm happy to have a go making a PR for all of these packages with the following process: archive from cache (by with subsituters) archive from both and confirm tar files are identical hash according to newly retrieved archive But if there's a better process, please let me know :) Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Sounds good
I think it is preferable to switch all affected derivations to fetchzip. This should prevent this from happening again, if the actual content of the tarball is the same. Even better, you could add a fetchFromSourceHut function which uses fetchzip under the hood, like fetchFromGitHub and fetchFromGitLab. This would encourage people not to use fetchurl to fetch procedurally generated tarballs from sourcehut.
From a quick look at the ticket, this is supposed to be a one-time change to make the hash the same as in other forges though
I think getting the new hashes with e.g. should be enough (fetches securely via HTTPS and we should be able to trust that the contents remain unchanged). +1, that seems like the best (long-term) solution. Edit: And IMO we should keep using archives (e.g. because it's consistent with the GitHub and GitLab fetchers) and should indeed be fine now:
the point is: with fetchzip, we don't have to trust this pinky promise (I mean, I'm sure that they intend to keep it, but it could break unwillingly). That's exactly why fetchzip exists in the first place. So on fixes keeping fetchurl.
oh, my bad, I didn't read your comment carefully enough :o I thought you've meant vs. (which didn't make much sense) but realized now that it was vs. . :+1: for that then :)
Hah, same. too then
is merged now so you could submit a PR to switch the affected attributes/packages to the new (s. ). I can also take care of it if you want.
Change:
buildPythonPackage rec { pname = "nbclient"; <del> version = "0.5.8"; </del> <ins> version = "0.5.9"; </ins> disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; <del> sha256 = "sha256-NPUsycuDGl2MzXAxU341THXcYaJEh/mYcS0Sid4yCiU="; </del> <ins> sha256 = "sha256-meRt2vrNC4YSk78kb+2FQKGErfo6p9ZB+JAx7AcHAeA="; </ins> }; inherit doCheck; checkInputs = [ pytest xmltodict nbconvert ipywidgets ]; propagatedBuildInputs = [ async_generator traitlets nbformat nest-asyncio jupyter-client ]; <del> postFixup =  '' # Remove until fixed by upstream # https://github.com/jupyter/nbclient/pull/173#issuecomment-968760082 rm $out/bin/.jupyter-run-wrapped rm $out/bin/jupyter-run ''; </del> meta = with lib; { homepage = "https://github.com/jupyter/nbclient"; description = "A client library for executing notebooks";

Discussion:
When trying to start an environment containing , l get this error: Use this : Run . Notice that you get an error about a collision. Please run and paste the result.
This was fixed in master by and should hit unstable shortly. Can you confirm?
Change:
nativeBuildInputs = [ cmake python3 ispc ]; buildInputs = [ tbb ]; <ins> cmakeFlags = [ "-DTBB_ROOT=${tbb}" "-DTBB_INCLUDE_DIR=${tbb.dev}/include" ]; </ins> meta = with lib; { homepage = "https://openimagedenoise.github.io"; description = "High-Performance Denoising Library for Ray Tracing";

Discussion:
Steps to reproduce the behavior: Breaks since it depends on <!-- 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.
Possibly running an outdated version of TBB. Current release is 2021.7.0, the version in unstable is 2020.3. Of course, this could be on purpose.
This is very likely fallout from (more precisely, commit ). See also (broken in a similar fashion) See the following Hydra failures: embree: openimagedenoise: FYI
Change:
"cp -rT ${testDir} /opt", "touch /opt/excluded_file_1 /opt/excluded_file_2", "mkdir -p /root/restic-rclone-backup", <ins> "restic-remote-noinit-backup init", </ins> # test that remotebackup runs custom commands and produces a snapshot "timedatectl set-time '2016-12-13 13:45'",

Discussion:
Recent changes to the assume the presence of the list even when it is not in use (it defaults to null). This prevents the service from running. Problem line: Steps to reproduce the behavior: a backup service without the 'dynamicFilesFrom' option that is included in the service's ExecStart service failing due to error Argument should not be passed if is not in use <!-- 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.
cc
Please provide the relevant part of your configuration hughobrien am Mi., 1. Nov. 2023, 01:07:
The problematic section is unconditional so I do not believe the config matters. Nevertheless
Ah, I see. I'll send a fix in the evening. In the meantime, you can work around the problem by setting (which does not change anything if the repository already exists). hughobrien am Mi., 1. Nov. 2023, 15:08:
Change:
enableParallelBuilding = true; <ins> shellHook = '' # to be able to run the resulting binary export WIRESHARK_RUN_FROM_BUILD_DIRECTORY=1 ''; </ins> meta = with stdenv.lib; { homepage = https://www.wireshark.org/; description = "Powerful network protocol analyzer";

Discussion:
After compiling wireshark in a nix-shell, if you try to run the binary, it can't find libwscodec, a wireshark-specific library. I solved it in an overlay via: but I dunno if it's the correct way to solve it in the derivation ? nixos- (Impala) nix version: nix-env (Nix) 1.11.15 Nixpkgs version: "" sandboxing disabled
You mean running the binary from the build tree without ? That's probably an upstream problem (or rather, works as designed).
Yes. I just run buildPhase then i run the "build/run/wireshark" binary. I haven't developed in a long time for wireshark but it suddenly came back to me that you have to do (see ) It's a bit unpractical and not completely foolproof as it doesn't find other libraries too but it doesn't stop the main binary from running. Problem solved. My bad.