jiebi/CodeConvo huggingface dataset:
Change:
<ins> let defaultPort = 8080; customPort = 4242; in import ./make-test-python.nix ({ pkgs, ... }: { name = "podgrab"; nodes = { default = { ... }: { services.podgrab.enable = true; }; customized = { ... }: { services.podgrab = { enable = true; port = customPort; }; }; }; testScript = '' start_all() default.wait_for_unit("podgrab") default.wait_for_open_port("${toString defaultPort}") default.succeed("curl --fail http://localhost:${toString defaultPort}") customized.wait_for_unit("podgrab") customized.wait_for_open_port("${toString customPort}") customized.succeed("curl --fail http://localhost:${toString customPort}") ''; meta.maintainers = with pkgs.lib.maintainers; [ ambroisie ]; }) </ins>

Discussion:
Project description Podgrab is a is a self-hosted podcast manager which automatically downloads latest podcast episodes. It is a light-weight application built using GO. It works best if you already know which podcasts you want to monitor. However there is a podcast search system powered by iTunes built into Podgrab Metadata homepage URL: source URL: license: gpl3 (I think, see about a typo) platforms: unix, I think, it's a Go package
If I have some time this week-end, I might tackle this issue myself. The repo has and files so it should be pretty easy for a first contribution :-)
So I'm having issues with the package's tests, I have opened an upstream issue to discuss it.
Change:
in buildNodejs { inherit enableNpm; <del> version = "20.3.0"; sha256 = "sha256-G6jUlCPtOnVykGa7PqJkk+6ct9ZWjvlIWX/J70VPdDU="; </del> <ins> version = "20.3.1"; sha256 = "sha256-EqgtswZpeVm0OJs1Gl+XhImGsTE/mQGw4LPYz08/mZE="; </ins> patches = [ ./revert-arm64-pointer-auth.patch ./disable-darwin-v8-system-instrumentation-node19.patch

Discussion:
Package name: NodeJS Latest released version: 16.20.1, 18.16.1, 20.3.1 <!-- Search your package here: --- Current version on the unstable channel: 16.20.0, 18.16.0, 20.3.0 Current version on the stable/release channel: 16.20.0, 18.16.0, 20.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.
Change:
owner = "smallstep"; repo = "cli"; rev = "refs/tags/v${version}"; <del> hash = "sha256-lM42KlTgOch6AwQIzvjQNH1wVfFikVI9rVgH2/2KyJE="; </del> <ins> hash = "sha256-9w7rUtlLa1kl9oVboWZWj4eoZh+pPdGsEEQDWYdEMns="; </ins> }; ldflags = [

Discussion:
Steps to reproduce the behavior: step-cli Not sure what happened. Did upstream force-push update the tag? <!-- 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]:
seems to have built fine for me on latest, being .
Ofborg on failed with same error on hash mismatch around 5 hours ago: x8664-darwin finished 2024-07-23T03:50:19Z Other two were successful, but they finished much earlier: x8664-linux finished 2024-07-22T08:16:54Z aarch64-linux finished 2024-07-22T08:17:43Z
To check you probably need to add , ie:
Change:
{ lib, stdenv, buildLinux, fetchFromGitHub, ... } @ args: let <del> version = "5.14.16"; </del> <ins> version = "5.15.2"; </ins> release = "1"; <del> suffix = "xanmod${release}-cacule"; </del> <ins> suffix = "xanmod${release}-tt"; </ins> in buildLinux (args // rec { inherit version;

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 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: linuxKernel.kernels.linux_xanmod <!-- 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: 5.14.16 desired version: 5.15.2-xanmod1-tt <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: This package represents xanmod-cacule(xanmod + cacule cpu scheduler), but xanmod-cacule has been replaced by , so this packages should point to it. I also suggest using the correct versioning, so instead of using 5.15.2 we should use 5.15.2-xanmod1-tt considering that 5.15.2-xanmod2-tt could be released. We could also change the name of this package to linux-xanmod-tt and maybe create another package called just linux-xanmod for the default . Please tag this issue in your PR.
Change:
btrfsProgs = throw "'btrfsProgs' has been renamed to/replaced by 'btrfs-progs'"; # Converted to throw 2022-02-22 bud = throw "bud has been removed: abandoned by upstream"; # Added 2022-03-14 inherit (libsForQt5.mauiPackages) buho; # added 2022-05-17 <ins> bukut = throw "bukut has been removed since it has been archived by upstream"; # Added 2023-05-24 </ins> buttersink = throw "buttersink has been removed: abandoned by upstream"; # Added 2022-04-05 # Shorter names; keep the longer name for back-compat. Added 2023-04-11 buildFHSUserEnv = buildFHSEnv;

Discussion:
do you still use bukut ? I just noticed the project was archived . If the software is useful I wouldn't mind keeping it but the value looks think compared to buku or rofi-buku etc. Do you still use it/should we remove it
I don't use it anymore. I would appreciate its removal. If not, I can remove it.
this (fig)soda is lethal ! well done
Change:
<ins> Use full bash's sh in tests instead of /bin/sh, as that would be too minimalist in the build sandbox.  See issue: https://github.com/NixOS/nixpkgs/issues/110149#issuecomment-874258128 diff --git a/test/extracttest b/test/extracttest --- a/test/extracttest +++ b/test/extracttest @@ -9,2 +9,3 @@ setupTests() { $SUT $* archive makeself-test.run "Test $*" echo Testing +  sed "1s|/bin|$(dirname "$SHELL")|" -i ./makeself-test.run } </ins>

Discussion:
Currently the nixos-unstable channel is blocked because is failing due to its dependency : I haven’t been able to reproduce this locally. The error doesn’t make sense. It seems to come from : But plainly is not less than 1, unless there’s a signed 32-bit overflow bug in , which I don’t think there is? Is something wacky on Hydra? Notify maintainers Maintainer information:
This problem has been appearing randomly for months at least. I had looked into it a bit, but I had no idea what's wrong. A few retries usually work around it.
Cc in case you have any ideas?
Not really sure, but I'd check what the output of the command gives you since that's what's used to determine disk space. Maybe the filesystem is reporting this erroneously.
Currently not channel blocking so I changed the label.
This has blocked the last two nixos-unstable updates again (among other failures).
So, it really is 31-bit overflow in our default build-time :
... and cross-ref to upstream:
Change:
# shellcheck disable=SC2154 moveKF6DevTools() { <del> moveToOutput "${qtPluginPrefix}/designer" "${!outputDev}" </del> <ins> if [ -n "$devtools" ]; then mkdir -p "$devtools" moveToOutput "${qtPluginPrefix}/designer" "$devtools" fi </ins> } postInstallHooks+=('moveKF6DevTools')

Discussion:
retains references to packages, bloating the closure massively. I'd expect to see no such results. If comparing to qt5: n/a Seems related to some wrapping issue. For example: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --All examples above were built against Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Do we need the qt6 plugins for designer?
I achieved the following nix diff-closures with the diff: The patch is not perfect but maybe a starting point?
Maybe a separate output that's not $dev for those plugins?
That change brings the closure from (nominally) 1.05 GiB to 925 MiB. I think the other notably sized dependency would be which appears to add 100+ MiB of its own (as it brings along ), but it's indirectly coming from
Change:
chkrootkit = callPackage ../tools/security/chkrootkit { }; <ins> chrony = callPackage ../tools/networking/chrony { }; </ins> cksfv = callPackage ../tools/networking/cksfv { }; ciopfs = callPackage ../tools/filesystems/ciopfs { };

Discussion:
"command-line application to view images from the terminal written in Rust" I tested it and it seems to be good and useful.
Change:
<ins> { lib , stdenv , fetchFromGitLab , autoreconfHook , pkg-config , utilmacros , libX11 , libXaw , libXmu , libXt }: stdenv.mkDerivation rec { pname = "xedit"; version = "1.2.2"; src = fetchFromGitLab { domain = "gitlab.freedesktop.org"; owner = "xorg/app"; repo = "xedit"; rev = "${pname}-${version}"; sha256 = "0b5ic13aasv6zh20v2k7zyxsqbnsxfq5rs3w8nwzl1gklmgrjxa3"; }; nativeBuildInputs = [ autoreconfHook pkg-config utilmacros ]; buildInputs = [ libX11 libXaw libXmu libXt ]; configureFlags = [ "--with-lispdir=$out/share/X11/xedit/lisp" "--with-appdefaultdir=$out/share/X11/app-defaults" ]; meta = with lib; { description = "Simple graphical text editor using Athena Widgets (Xaw)"; homepage = "https://gitlab.freedesktop.org/xorg/app/xedit"; license = with licenses; [ mit ]; maintainers = with maintainers; [ shamilton ]; platforms = platforms.linux; }; } </ins>

Discussion:
Project description On some installations this simple text editor even has syntax highlightning, but it might require non-trivial amounts of work to get that part to work. Metadata homepage URL: source URL: Gitlab, , tag = or alternatively: latest current version: 1.2.2 license: MIT (according to the ebuild in the Gentoo repository) platforms: at least linux, but might also support other platforms with X11 support
I marked this as stale due to inactivity. &rarr;
I still need this.
Change:
let pname = "sparrow"; <del> version = "1.7.1"; </del> <ins> version = "1.7.3"; </ins> src = fetchurl { url = "https://github.com/sparrowwallet/${pname}/releases/download/${version}/${pname}-${version}-x86_64.tar.gz"; <del> sha256 = "0q31b4ncvbhr9gb47wplphg43pwlg5vpd1b12qiidqlrkgm2vjy8"; </del> <ins> sha256 = "sha256-/tKct73v0zWAjY4kTllnb/+SB/8ENgVl8Yh/LErKTxY="; </ins> }; launcher = writeScript "sparrow" ''

Discussion:
Steps to reproduce the behavior: sparrow 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.
TLDR; This was caused by and is fixed in Upstream bundles a JDK/JRE with sparrow. Our sparrow package does not use the bundled JDK and instead replaces it with a JDK from Nixpkgs. Since the sparrow bundle contains the JDK and the sparrow code in a single JIMAGE, the sparrow package compares the files in the JIMAGE with the files provided by the JDK in Nixpkgs in order to determine which files in the JIMAGE are part of the JDK. Those files are then excluded from the sparrow derivation. When disabled JavaFX by default it changed the output of the aforementioned comparison, leaving behind some files which belong to the JDK as part of the sparrow derivation; The files which are part of JavaFX. This in turn causes the patchelf procedure to fail because the sparrow package is only expected to patch sparrow-specific dependencies, not the JDK.
Change:
<ins> /* This file provides the `tectonic-unwrapped` package. On the other hand, the `tectonic` package is defined in `./wrapper.nix`, by wrapping - [`tectonic-unwrapped`](./default.nix) i.e. this package, and - [`biber-for-tectonic`](./biber.nix), which provides a compatible version of `biber`. */ </ins> { lib , stdenv , fetchFromGitHub

Discussion:
Describe the bug Reproduction  Expected behavior No errors Notify maintainers Metadata Maintainer information:
The version of biber that we ship corresponds to . ships with texlive 2018 (tectonic-typesetting/tectonic-staging). And doesn't yet have a builtin solution for biber tectonic-typesetting/tectonic. You can try overriding biber to version 2.11, which should be compatible. cc as maintainer of
I would also appreciate a fix for this. I tried overriding to version 2.11, but that didn't help (similar version incompatibility), at least not on the current unstable channel or on 20.03 to match with the date of message. The version in the current derivation seems to be 3.3, which dates back to 2016, so it looks like updating would make more sense.
I marked this as stale due to inactivity. &rarr;
I've just encountered this issue too.
Which version of nixpkgs are you using? What is the output of:
Currently biber expects while nixpkgs (as well as texlive) contains . For me the override suggested in works with no issue; e.g. with home-manager: Although this works on my end, I hope this could be upstreamed to nixpkgs itself so that we can make use of the hydra cache with no need to locally rebuild tectonic; cc maintainers: Thank you very much!
Tectonic is tracking this issue in . In general, we sort of rely on Tectonic's bundles to follow texlive releases. That's why we don't embed such hardcoding of the version in Tectonic - since Tectonic could update it's bundle without an update to Tectonic itself, which could fix such an issue if it arises after a Tectonic release. Perhaps also the following Tectonic nixpkgs update will help:
Indeed... Is it then possible to create some package without the dependency, so that we can install the appropriate versions of and separately, without the need to recompile the package? :thinking: Thanks!
You have a point. I was the one who introduced the wrapping of with in ... I tend to think now that it shouldn't be that way, especially with this frequent issue of incompatibility. I pushed that as well to .

Wow nice! Thank you very much!
I have hence created a wrapper so that one can combine the two into a single package, where the -specific biber is renamed to prevent conflict with the texlive biber: I am far from proficient in nix, so the package is created following along with the previous revision of . It can be used e.g. as an override: I don't know whether it's good to upstream this or not. In any case, I think it may be useful to others like me, so it would be good to share this here haha.
Update: I am now trying to upstream a more polished solution via . would you be interested in a review? :pleading_face: The PR will close this issue.
Change:
<ins> { stdenv , buildBazelPackage , fetchFromGitHub , cacert , git , glibcLocales , go , iproute , iptables , makeWrapper , procps , python3 }: let preBuild = '' patchShebangs . # Tell rules_go to use the Go binary found in the PATH sed -E -i  -e 's|go_versions*=s*"[^"]+",|go_version = "host",|g'  WORKSPACE # The gazelle Go tooling needs CA certs export SSL_CERT_FILE="${cacert}/etc/ssl/certs/ca-bundle.crt" # If we don't reset our GOPATH, the rules_go stdlib builder tries to # install something into it. Ideally that wouldn't happen, but for now we # can also get around it by unsetting GOPATH entirely, since rules_go # doesn't need it. export GOPATH= ''; in buildBazelPackage rec { name = "gvisor-${version}"; version = "2019-11-14"; src = fetchFromGitHub { owner = "google"; repo  = "gvisor"; rev   = "release-20191114.0"; sha256 = "0kyixjjlws9iz2r2srgpdd4rrq94vpxkmh2rmmzxd9mcqy2i9bg1"; }; nativeBuildInputs = [ git glibcLocales go makeWrapper python3 ]; bazelTarget = "//runsc:runsc"; # gvisor uses the Starlark implementation of rules_cc, not the built-in one, # so we shouldn't delete it from our dependencies. removeRulesCC = false; fetchAttrs = { inherit preBuild; preInstall = '' # Remove the go_sdk (it's just a copy of the go derivation) and all # references to it from the marker files. Bazel does not need to download # this sdk because we have patched the WORKSPACE file to point to the one # currently present in PATH. Without removing the go_sdk from the marker # file, the hash of it will change anytime the Go derivation changes and # that would lead to impurities in the marker files which would result in # a different sha256 for the fetch phase. rm -rf $bazelOut/external/{go_sdk,@go_sdk.marker} # Remove the gazelle tools, they contain go binaries that are built # non-deterministically. As long as the gazelle version matches the tools # should be equivalent. rm -rf $bazelOut/external/{bazel_gazelle_go_repository_tools,@bazel_gazelle_go_repository_tools.marker} # Remove the gazelle repository cache chmod -R +w $bazelOut/external/bazel_gazelle_go_repository_cache rm -rf $bazelOut/external/{bazel_gazelle_go_repository_cache,@bazel_gazelle_go_repository_cache.marker} # Remove log file(s) rm -f "$bazelOut"/java.log "$bazelOut"/java.log.* ''; sha256 = "122qk6iv8hd7g2a84y9aqqhij4r0m47vpxzbqhhh6k5livc73qd6"; }; buildAttrs = { inherit preBuild; installPhase = '' install -Dm755 bazel-bin/runsc/*_pure_stripped/runsc $out/bin/runsc # Needed for the 'runsc do' subcomand wrapProgram $out/bin/runsc  --prefix PATH : ${stdenv.lib.makeBinPath [ iproute iptables procps ]} ''; }; meta = with stdenv.lib; { description = "Container Runtime Sandbox"; homepage = https://github.com/google/gvisor; license = licenses.asl20; maintainers = with maintainers; [ andrew-d ]; platforms = [ "x86_64-linux" ]; }; } </ins>

Discussion:
"Sandboxed container runtime" Bonus points for NixOS option for docker support :P. But just having it to poke at would be neat, i think!
I've looked quickly at this, and it seems like the main limitation in implementing this is . I think we either have to patch Bazel in NixOS or any Bazel package that compiles Go to fix this...
Change:
sha256 = "0d46bdvxdiv59lxnb0xz9ywm8arsr6xsapi5s6y6vnys2wjz6aax"; }; <del> outputs = [ "bin" "dev" "out" "man" "doc" ]; </del> <ins> # FreeImage needs this patch patches = [ ./headers.patch ]; </ins> <del> nativeBuildInputs = [ pkgconfig ]; </del> <ins> outputs = [ "bin" "dev" "dev_private" "out" "man" "doc" ]; postFixup = '' moveToOutput include/tif_dir.h $dev_private moveToOutput include/tif_config.h $dev_private moveToOutput include/tiffiop.h $dev_private ''; nativeBuildInputs = [ cmake pkgconfig ]; </ins> propagatedBuildInputs = [ zlib libjpeg xz ]; #TODO: opengl support (bogus configure detection) enableParallelBuilding = true; <del> doCheck = true; # not cross; </del> <ins> doInstallCheck = true; installCheckTarget = "test"; </ins> meta = with stdenv.lib; { description = "Library and utilities for working with the TIFF image file format";

Discussion:
Describe the bug I am trying to build for . is one giving me difficulty. Originally I filed an issue on : But the issue is instead with the libpng inside freeimage: Basically, libpng applies an incorrect ARM optimization to aarch64 that isn't actually available. From briefly looking at in nixpkgs, it seems that we patch with patches (and skimming that, it looks like it has a relevant aarch64 patch). So, my goal is to patch the vendored inside FreeImage, similar to how we patch itself. So far I've not had luck. I've tried with both the CRLF and LF patches from the 'apng' project and the regular patch used from the 'libpng-apng' project that is used in nixpkg's libpng. They all fail to apply and some complain about line endings, regardless of if I pipe the patch through dos2unix (or unix2dos) or not.
I seem to have fixed this by patching libpng inside of the freeimage source using the same patch as the derivation.. I'm just debating whether or not to allow it to be toggle-able as it is in the libpng derivation.
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
still important to me
I marked this as stale due to inactivity. &rarr;
still important to me
You can close this I think
Change:
in stdenv.mkDerivation rec { <del> name = "aspell-0.60.6.1"; </del> <ins> name = "aspell-0.60.8"; </ins> src = fetchurl { url = "mirror://gnu/aspell/${name}.tar.gz"; <del> sha256 = "1qgn5psfyhbrnap275xjfrzppf5a83fb67gpql0kfqv37al869gm"; </del> <ins> sha256 = "1wi60ankalmh8ds7nplz434jd7j94gdvbahdwsr539rlad8pxdzr"; </ins> }; <del> patches = [ (fetchpatch { # remove in >= 0.60.7 name = "gcc-7.patch"; url = "https://github.com/GNUAspell/aspell/commit/8089fa02122fed0a.diff"; sha256 = "1b3p1zy2lqr2fknddckm58hyk95hw4scf6hzjny1v9iaic2p37ix"; }) (fetchpatch { name = "CVE-2019-17544.patch"; url = "https://github.com/GNUAspell/aspell/commit/80fa26c74279fced8d778351cff19d1d8f44fe4e.patch"; sha256 = "0k5dnh8gcb7chnyx7jgkksqmz2hm05hmrvcd0znsfib975pvp4rg"; }) ] ++ stdenv.lib.optional searchNixProfiles ./data-dirs-from-nix-profiles.patch; </del> <ins> patches = stdenv.lib.optional searchNixProfiles ./data-dirs-from-nix-profiles.patch; </ins> postPatch = '' patch interfaces/cc/aspell.h < ${./clang.patch} ''; <del> nativeBuildInputs = [ perl ]; </del> <ins> buildInputs = [ perl ]; </ins> doCheck = true;

Discussion:
, CVSSv3=9.1 (nixos-19.09) Scanned versions: nixos-19.09: . May contain false positives.
See also:
The upstream advisory mentions the fix could break some apps, so I suggest a proper version bump on stable.
this issue is still valid
Oops sorry
CVE-2019-: Fixed at version 0.60.8 (nixos-19.09, nixos-20.03, nixos-unstable).

, (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
CVE-2019-: Fixed at version 0.60.8 (nixos-19.09, nixos-20.03, nixos-unstable).
Change:
inherit (pkgs.buildPackages) makeSetupHook makeWrapper; }; <del> luarocks = toLuaModule (callPackage ../development/tools/misc/luarocks/default.nix { }); </del> <ins> luarocks_bootstrap = toLuaModule (callPackage ../development/tools/misc/luarocks/default.nix { }); </ins> # a fork of luarocks used to generate nix lua derivations from rockspecs luarocks-nix = toLuaModule (callPackage ../development/tools/misc/luarocks/luarocks-nix.nix { });

Discussion:
luarocks exists that other luarocks packages can depend on. When trying to build a rockspec that depends on luarocks with , it fails. The entry in the generated luarocks config contains an entry for luarocks, but luarocks doesn't recognise it and tries to download the package instead. I have created a repository to reproduce it with: Run A workaround is to use to generate a expression for luarocks (), and to add that package to the 's instead of the package from nixpkgs. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for creating the test repo, it's helpful. I've looked at the generated LUAROCKSCONFIG and all looks good and I think luarocks just doesn't recognize the installed luarocks because of My first thought would have been to rename the current luarocks into a luarocksbootstrap and add a generated derivation, for which we could run the tests without the cyclic dependency luarocks -busted -luarocks. While this might be the best outcome longterm, I am looking into the quickfix which would be to generate the manifest for the current luarocks