jiebi/CodeConvo huggingface dataset:
Change:
Package name: cypress Latest released version: 13.13.2 <!-- Search your package here: --- Current version on the unstable channel: 13.2.0 Current version on the stable/release channel: 13.2.0 <!-- 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! --- The following PR exists but seems to be abandoned: Weirdly enough I am also experiencing that the 13.2.0 version actually delivers 12.17.1, I don't know why...: ! Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Discussion:
availableBinaries = { x86_64-linux = { platform = "linux-x64"; <del> checksum = "sha256-9o0nprGcJhudS1LNm+T7Vf0Dwd1RBauYKI+w1FBQ3ZM="; </del> <ins> checksum = "sha256-zS/yMXNNYlxgYyUDou2HaXuetPotqiOM8kv1Y7JouCo="; </ins> }; aarch64-linux = { platform = "linux-arm64"; <del> checksum = "sha256-aW3cUZqAdiOLzOC9BQM/bTkDVyw24Dx9nBSXgbiKe4c="; </del> <ins> checksum = "sha256-rB0ak6jYnJMb0aHDLAyhaGoOFK4FXDLEOeofNdW/Wk8="; </ins> }; }; inherit (stdenv.hostPlatform) system;

inherit (binary) platform checksum; in stdenv.mkDerivation rec { pname = "cypress"; <del> version = "13.2.0"; </del> <ins> version = "13.13.2"; </ins> src = fetchzip { url = "https://cdn.cypress.io/desktop/${version}/${platform}/cypress.zip";
Change:
Steps to reproduce the behavior: on aarch64-darwin also since was merged not so long ago, it might be the issue, I'm checking this Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It build fine on == , but not on . It also build fine on current master () after a .
Uh, weird. The patches I are specifically meant to address this. Maybe there’s some macOS‐only FFmpeg code path somehow? I thought Qt WebEngine was just broken on Darwin so I didn’t think to test the build there, sorry; apparently it’s only Qt 6 that has that problem. I’ll try to look into this soon.
Wait, is the new API. I’m confused. All I can think is either: isn’t FFmpeg 7 for you (and Hydra?) somehow, or ’re not actually using that FFmpeg 7 (using the vendored one instead but only on Drawin maybe?).
I guess we need to patch the build system to allow using the system FFmpeg on macOS too?
fine: I'll try with in
I've edited the log: it is more clear that the issue is in building vendored ffmpeg. So if building with system ffmpeg fails, I guess we could try to patch the vendored one
Yeah, I was working on a patch for this. We might need to do something more to get it to actually link with ours. Let me know if it works or not though :)
Yes, there are linking issues:
Thanks. Unfortunately I don’t fully understand their build system. I can see in is getting from , which should be working, but I’m failing to trace it to why it’s not getting used on macOS.
Ah, I suspect I may need to look in their Chromium fork rather than the WebEngine wrapper…
Okay, there’s a that presumably needs duplicating over in the macOS stuff. I’ll try and get a PR up tonight if it seems to work.
I’m afraid Chromium’s build system continues to confound me. I can’t figure out what the logic is that causes to be used on Linux (if it even is), and there’s a script in there that nothing at all seems to reference. Maybe I’m barking up the wrong tree as pertains to FFmpeg…

Discussion:
# ld: fatal warning(s) induced error (-fatal_warnings) substituteInPlace src/3rdparty/chromium/build/config/compiler/BUILD.gn  --replace "-Wl,-fatal_warnings" "" <ins> # Use system ffmpeg echo "gn_args += use_system_ffmpeg=true" >> src/core/config/mac_osx.pri echo "LIBS += -lavformat -lavcodec -lavutil" >> src/core/core_common.pri </ins> '') + postPatch; env = {
Change:
The following message appears whenever I start digiKam: Steps to reproduce the behavior: digiKam from current unstable digiKam All tools necessary for digiKam should be in its derivation. ! system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hmm, it’s never had ExifTool in the so this at least shouldn’t be my fault. It might be as simple as just adding it . Looks like we could also patch .
It looks like it's been reporting "ExifTool process cannot be started" since at least .

Discussion:
bison, wrapGAppsHook3, <ins> exiftool, </ins> opencv, libtiff, libpng,

gnumake hugin enblend-enfuse <ins> exiftool </ins> ] }) qtWrapperArgs+=(--suffix DK_PLUGIN_PATH : ${placeholder "out"}/${kdePackages.qtbase.qtPluginPrefix}/digikam) substituteInPlace $out/bin/digitaglinktree  <del> --replace "/usr/bin/perl" "${perl}/bin/perl"  --replace "/usr/bin/sqlite3" "${sqlite}/bin/sqlite3" </del> <ins> --replace "/usr/bin/perl" "${lib.getExe perl}"  --replace "/usr/bin/sqlite3" "${lib.getExe sqlite}" </ins> ''; meta = {
Change:
Build fails on running tests Steps to reproduce the behavior: Full log: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hydra builds (never build successfully on python 3.12): Upstream seems to be have been hit by this: which was made into an error with python 3.12 This assert was always true:

Discussion:
lib, buildPythonPackage, fetchPypi, <ins> fetchpatch2, </ins> # build-system flit-core,

hash = "sha256-QTLSEjdJtDH4GCamnKHN5pEjW41rRtAMXxyZZMM5K3w="; }; <ins> patches = [ # fix build with python 3.12 # https://github.com/florisla/stm32loader/pull/79 (fetchpatch2 { url = "https://github.com/florisla/stm32loader/commit/96f59b2984b0d0371b2da0360d6e8d94d0b39a68.patch?full_index=1"; hash = "sha256-JUEjQWOnzeMA1OELS214OR7+MYUkCKN5lxwsmRoFbfo="; }) ]; </ins> nativeBuildInputs = [ flit-core ]; propagatedBuildInputs = [
Change:
Steps to reproduce the behavior: <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The build fails with
Adding to the buildInputs fixes the issue, I'll create a PR…
Mind giving the PR commit a try,
Supah! Now I can continue setting up valhalla. :+1:
Happy I could help, a review and formal approval on would greatly be appreciated and help move the PR addressing this issue forward

Discussion:
, librttopo , libspatialite , libxml2 <ins> , libz </ins> , minizip , proj , readosm

librttopo libspatialite libxml2 <ins> libz </ins> minizip proj readosm
Change:
Project description It's a conventional commits git helper that has a gorgeous TUI Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, (basicaly anything with go) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Name conflicts with .
I think renaming it to meteor-git would solve that

Discussion:
githubId = 2287221; name = "Andreas Zweili"; }; <ins> nebunebu = { email = "neb.nebuchadnezzar@gmail.com"; github = "nebunebu"; githubId = 87451010; name = "nebu"; }; </ins> Necior = { email = "adrian@sadlocha.eu"; github = "Necior";

<ins> { lib, fetchFromGitHub, buildGoModule, }: buildGoModule rec { pname = "meteor-git"; version = "0.22.0"; src = fetchFromGitHub { owner = "stefanlogue"; repo = "meteor"; rev = "v${version}"; hash = "sha256-aY/gOKvcKtOnL4FI2SM339LU4HoWYCq0W9mK2GyMqso="; }; vendorHash = "sha256-jKd/eJwp5SZvTrP3RN7xT7ibAB0PQondGR3RT+HQXIo="; meta = { description = "CLI tool for writing conventional commits"; mainProgram = "meteor"; homepage = "https://github.com/stefanlogue/meteor"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ nebunebu ]; }; } </ins>
Change:
The xdg-user-dirs package contains a file named . A module allowing to customize this file would be great.
GNOME users, at least, already have generated in their profile by the . That would override the XDG module.
The command, executed in the GNOME session script you are referring to, reads the file, translates it if needed and places it in . Yes, this is exactly what I am talking about. If can be customized, then the GNOME session script would copy the customized one.
This looks like a duplicate of . The environment variable determines the search paths for . This is currently as a profile-relative path variable. For this to work, I think it would also need to define as a profile non-relative path so that a module could produce the file in that path.
I'm also interested in a way to customize xdg-user-dirs
There is little need for dedicated options, you can just use in your .
It does not work... What I have tried so far in a VM: removing the user homedir + changing to + removing the user homedir + changing to + removing the user homedir + I am using Gnome as a DE and the following user-dirs structure:
will not be enough. relies on to run so you need to re-login for it to be triggered.
I did reboot the VM after every and then logged in as the unpriviledged user
Hmm, apparently, it should have been , not or .
... sorry for the delay... But I just tried with only this And it does not use the user-dirs I configure above
Okay, there are several issues here: correctly points out, is profile-relative variable and since it is set, will not be used as per the : could add to which would add it to but that will conflict with the file from the preset file from the package . , I have came up with the following abomination to add to your : But again, it does not work. Turns out we are prefixing the with presets when running as well. With the patch and the horrendous snippet, I can confirm the expected directories were created. We should try to find out how to make the environment variable contain before all the profile-related stuff so that the simple solution works.
now contains full fix enabling us to use as suggested in
Awesome .... I just built from your branch and works like a charm. Thanks a lot, I owe you one The config I'm currently using after the developments in is...
you probably want to reopen this, because functionality implemented here is currently broken. Please see:
As mentioned in the , there is a prerequisite of and having something that runs autostart entries (which DEs like GNOME or Plasma do out of the box).

Discussion:
PAGER = mkDefault "less -R"; EDITOR = mkDefault "nano"; XCURSOR_PATH = [ "$HOME/.icons" ]; <ins> XDG_CONFIG_DIRS = [ "/etc/xdg" ]; # needs to be before profile-relative paths to allow changes through environment.etc </ins> }; environment.profiles = mkAfter

buildInputs = [ libxslt docbook_xsl makeWrapper ]; preFixup = '' <ins> # fallback values need to be last </ins> wrapProgram "$out/bin/xdg-user-dirs-update"  <del> --prefix XDG_CONFIG_DIRS : "$out/etc/xdg" </del> <ins> --suffix XDG_CONFIG_DIRS : "$out/etc/xdg" </ins> ''; meta = with stdenv.lib; {
Change:
& contain a wrong path to the git-annex binary. Steps to reproduce the behavior: the 1st file path mentioned above can see: The desktop files should contain the real path to the git-annex binary. 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Discussion:
# (this should be possible by also taking PREFIX into account). ./patches/git-annex-no-usr-prefix.patch ]; <ins> postPatch = '' substituteInPlace Makefile  --replace-fail 'InstallDesktopFile $(PREFIX)/bin/git-annex'  'InstallDesktopFile git-annex' ''; </ins> }) super.git-annex; # Too strict bounds on servant
Change:
I used to be able to run Digikam like so: But for a few days now, I've been getting the following error: I'm running Hyprland, and setting in my session. I can force the app to run by setting , though things are very ugly! Steps to reproduce the behavior: The app should launch, respecting the configured theme. - I can see you're not listed as a maintainer, though I also see a lot of commits against - I hope it's okay to ping! Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I also noticed you doing some work on qt apps - not sure if you'll have an opinion here? :)
I've gone back through the commits, building Digikam each time, and the last working commit seems to be , before the transition to 8.4.0 and qt6.
I know this sounds really stupid, but this can be worked around by adding to a package set. It could be to the expression, but it might make more sense to add it to the qt wrapper.
Wait, does that mean that Qt 6 applications don’t work with Wayland out of the box? That’s very strange if so, and does indeed seem like something better handled in a wrapper than in every leaf package.
Well they do work, they will just run in an X window rather than native Wayland.
PS exiftool should no longer be required in a day or two: https://nixpkgs-
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Discussion:
kdePackages.qtnetworkauth kdePackages.qtscxml kdePackages.qtsvg <ins> kdePackages.qtwayland </ins> kdePackages.qtwebengine kdePackages.qt5compat kdePackages.qtmultimedia
Change:
Steps to reproduce the behavior: status: status: status: This was discovered via pr <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It seems like some tests have began to fail. When testing, the traceback shows the following tests fail because they don't initialize the module correctly (with ). - These tests don't undermine the functionality of when building from source, so I'm inclined to believe that the culprit is itself. Looking further, throws various deprecation warnings when the tests run. I fear that the more NixOS receives updates to , the more the tests will become more deprecated. It's unclear how NixOS feels about packages and their tests (particularly whether it's necessary for a maintainer to maintain package tests), but the current workaround is to disable these tests. Adding the tests to the field produces the result package, and continues to work as normal. I'd like some input on how to approach as this does feel pretty hacky.
We could override pytest back to a previous working version. I looked to the upstream package and it hasn't been updated in a year, to which was just a readme update.
Wouldn't this affect newer packages (assuming they use as a unit test framework) who utilize newer features of ? Though hacky, the solution I've suggested gets the job done. As mention previously, the failure of the tests don't influence 's functionality.
Disabling problematic tests is done a lot across nixpkgs. Since we know its still working when they are disabled it should be fine.

Discussion:
"tests" ]; <del> disabledTests = [ "test_datafile_download" ]; </del> <ins> # Disable tests that are problematic with pytest # Check NixOS/nixpkgs#333019 for more info about these disabledTests = [ "test_datafile_download" "test_display_get_input_str" "test_display_get_y_n" ]; </ins> pythonImportsCheck = [ "castero"
Change:
It is a needless abstraction. Just use , or more ideally condition on the individual fields. CC
Do you have a plan to get rid of crossDrv and nativeDrv too?
Hmm I forgot about that. I usually think of getting rid of all splicing, which is the sole reason those exist, but that's a lot harder. Just renaming those to match the others is a good first step.

Discussion:
enableParallelBuilding = true; <del> crossAttrs = { propagatedBuildInputs = [ flex.crossDrv cracklib.crossDrv ]; preConfigure = preConfigure + '' $crossConfig-ar x ${flex.crossDrv}/lib/libfl.a mv libyywrap.o libyywrap-target.o ar x ${flex}/lib/libfl.a mv libyywrap.o libyywrap-host.o export LDFLAGS="$LDFLAGS $PWD/libyywrap-target.o" sed -e 's/@CC@/gcc/' -i doc/specs/Makefile.in ''; postConfigure = '' sed -e "s@ $PWD/libyywrap-target.o@ $PWD/libyywrap-host.o@" -i doc/specs/Makefile ''; }; </del> postInstall = '' mv -v $out/sbin/unix_chkpwd{,.orig} ln -sv /run/wrappers/bin/unix_chkpwd $out/sbin/unix_chkpwd
Change:
Package name: intel-one-mono Latest released version: 1.4.0 <!-- Search your package here: --- Current version on the unstable channel: 1.3.0 Current version on the stable/release channel: 1.3.0 <!-- 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! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Discussion:
<del> { lib, stdenvNoCC, fetchurl, unzip }: </del> <ins> { lib, stdenvNoCC, fetchurl, unzip, }: </ins> stdenvNoCC.mkDerivation (finalAttrs: { pname = "intel-one-mono"; <del> version = "1.3.0"; </del> <ins> version = "1.4.0"; </ins> srcs = [ (fetchurl { url = "https://github.com/intel/intel-one-mono/releases/download/V${finalAttrs.version}/otf.zip"; <del> hash = "sha256-iZIfkXH+GplVwES4LaQBIaCWs7OKmEto9J2SpzvagSs="; </del> <ins> hash = "sha256-dO+O5mdAPHYHRbwS/F4ssWhFRBlPrT1TQJGcFzqCJ/w="; </ins> }) (fetchurl { url = "https://github.com/intel/intel-one-mono/releases/download/V${finalAttrs.version}/ttf.zip"; <del> hash = "sha256-EeUTEMuoTHKmuO5Uj0jjiDRF9t7jxbIy45nTWozlgfc="; </del> <ins> hash = "sha256-VIY1UtJdy5w/U2CylvyYDW4fv9AuDSFCJOi3jworzPA="; </ins> }) ]; sourceRoot = "."; <del> nativeBuildInputs = [ unzip ]; </del> <ins> nativeBuildInputs = [ unzip ]; </ins> installPhase = '' runHook preInstall

runHook postInstall ''; <del> meta = with lib; { </del> <ins> meta = { </ins> description = "Intel One Mono, an expressive monospaced font family that’s built with clarity, legibility, and the needs of developers in mind"; homepage = "https://github.com/intel/intel-one-mono"; changelog = "https://github.com/intel/intel-one-mono/releases/tag/V${finalAttrs.version}"; <del> license = licenses.ofl; maintainers = [ maintainers.simoneruffini ]; platforms = platforms.all; </del> <ins> license = lib.licenses.ofl; maintainers = with lib.maintainers; [ luftmensch-luftmensch simoneruffini ]; platforms = lib.platforms.all; </ins> }; })
Change:
Package name: sherlock Latest released version: v0.15.0 <!-- Search your package here: --- Current version on the unstable channel: 0-unstable-2024-06-09 Current version on the stable/release channel: 0-unstable-2024-05-15 <!-- 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! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Some extra info: Current version of sherlock may be broken potentially because it's outdated. The link is broken. Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'll work on updating this. Current sherlock version is also broken for me.

Discussion:
<del> { lib , fetchFromGitHub , makeWrapper , python3 , unstableGitUpdater , poetry </del> <ins> { lib, fetchFromGitHub, makeWrapper, python3, poetry, </ins> }: python3.pkgs.buildPythonApplication rec { pname = "sherlock"; <del> version = "0-unstable-2024-06-09"; </del> <ins> version = "0.15.0"; </ins> format = "pyproject"; src = fetchFromGitHub { owner = "sherlock-project"; repo = "sherlock"; <del> rev = "d678908c00f16c7f6c44efc0357cef713fa96739"; hash = "sha256-XAXDqbdHQta9OiupbPmmyp3TK1VLtDQ7CadsOei/6rs="; </del> <ins> rev = "refs/tags/v${version}"; hash = "sha256-+fQDvvwsLpiEvy+vC49AzlOA/KaKrhhpS97sZvFbpLA="; </ins> }; patches = [

runHook preInstall mkdir -p $out/bin $out/share <del> cp -R ./sherlock $out/share </del> <ins> cp -R ./sherlock_project $out/share </ins> runHook postInstall '';

postFixup = '' makeWrapper ${python3.interpreter} $out/bin/sherlock  --add-flags "-m"  <del> --add-flags "sherlock"  </del> <ins> --add-flags "sherlock_project"  </ins> --prefix PYTHONPATH : "$PYTHONPATH:$out/share" '';

pythonRelaxDepsHook ]; <del> pythonRelaxDeps = [ "stem" ]; </del> <ins> pythonRelaxDeps = [ "stem" ]; </ins> pytestFlagsArray = [ "-m" "'not online'" ]; <del> passthru.updateScript = unstableGitUpdater { hardcodeZeroVersion = true; }; meta = with lib; { </del> <ins> meta = { </ins> homepage = "https://sherlock-project.github.io/"; description = "Hunt down social media accounts by username across social networks"; <del> license = licenses.mit; </del> <ins> license = lib.licenses.mit; </ins> mainProgram = "sherlock"; <del> maintainers = with maintainers; [ applePrincess ]; </del> <ins> maintainers = with lib.maintainers; [ applePrincess ]; </ins> }; }
Change:
Steps to reproduce the behavior: quickfix The package does not build on macos (darwin) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Discussion:
<del> { lib, stdenv, fetchFromGitHub, fetchpatch, autoconf, automake, libtool }: </del> <ins> { lib, stdenv, fetchFromGitHub, fetchpatch, autoconf, automake, libtool, }: </ins> stdenv.mkDerivation rec { pname = "quickfix"; version = "1.15.1"; src = fetchFromGitHub { <del> owner = pname; repo = pname; rev =  "v${version}"; </del> <ins> owner = "quickfix"; repo = "quickfix"; rev = "v${version}"; </ins> sha256 = "1fgpwgvyw992mbiawgza34427aakn5zrik3sjld0i924a9d17qwg"; };

]; # autoreconfHook does not work <del> nativeBuildInputs = [ autoconf automake libtool ]; </del> <ins> nativeBuildInputs = [ autoconf automake libtool ]; </ins> enableParallelBuilding = true; <ins> postPatch = '' substituteInPlace bootstrap --replace-fail glibtoolize libtoolize ''; </ins> preConfigure = '' ./bootstrap '';

homepage = "http://www.quickfixengine.org"; license = licenses.free; # similar to BSD 4-clause maintainers = with maintainers; [ bhipple ]; <ins> broken = stdenv.isAarch64; </ins> }; }