jiebi/CodeConvo huggingface dataset:
Change:
<del> { stdenv, lib, fetchurl, cmake, ninja, pkg-config, libiconv, libintl , zlib, curl, cairo, freetype, fontconfig, lcms, libjpeg, openjpeg, fetchpatch </del> <ins> { stdenv , lib , fetchurl , fetchpatch , cairo , cmake , curl , fontconfig , freetype , lcms , libiconv , libintl , libjpeg , ninja , openjpeg , pkg-config , zlib </ins> , withData ? true, poppler_data , qt5Support ? false, qtbase ? null , introspectionSupport ? false, gobject-introspection ? null

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: nixos.poppler <!-- 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: 21.05.0 desired version: 21.06.01 <!-- 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. The current version of is causing evince to crash frequently:
Change:
fully_kiosk = ps: with ps; [ python-fullykiosk ]; <del> hass = [ ]; # missing hass-client </del> <ins> hass = ps: with ps; [ hass-client ]; </ins> hass_players = [ ]; jellyfin = ps: with ps; [

Discussion:
Project description hass-client is a Python library for connecting to Home Assistant over WebSockets and REST. It's maintained as part of the Music Assistant project. . It is an indirect missing dependency for the hass_players provider, because that provider depends on a set up hass provider. Metadata homepage URL: source URL: license: asl20 platforms: all / linux(?) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
unfreeRedistributable # osu-framework contains libbass.so in repository ]; sourceProvenance = with lib.sourceTypes; [ binaryNativeCode ]; <del> maintainers = with lib.maintainers; [ delan spacefault stepbrobd ]; </del> <ins> maintainers = with lib.maintainers; [ delan gepbird spacefault stepbrobd ]; </ins> mainProgram = "osu!"; platforms = [ "aarch64-darwin" "x86_64-darwin" "x86_64-linux" ]; };

Discussion:
Package name: osu-lazer Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 2023.815.0 Current version on the stable/release channel: 2023.511.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 Note for maintainers: Please tag this issue in your PR.
Change:
markdown,,,,, mediator_lua,,,,, mpack,,,,, <ins> moonscript,,,,,arobyn </ins> nvim-client,,,,, penlight,,,,, rapidjson,,,,,

Discussion:
In the process of trying to install pgmoon, I discovered than moonc wasn't available. Indeed, I can't find any reference in nixpkgs to except for an emacs mode. I can probably package this up, but I'm shocked to find that it's not already available; it's fairly obscure, but Nix has pretty good coverage. So I'll check to see if I'm just missing it (or if anyone has a nix expression for it handy) before spending the effort on it. Please run and paste the results. Odd....
Change:
<del> {lib, stdenv, fetchurl}: </del> <ins> { lib, stdenv, fetchurl, pkgsBuildBuild, autoreconfHook }: </ins> stdenv.mkDerivation rec { pname = "judy";

Discussion:
Describe the bug judy (a dependency of mariadb) fails to cross-compile. To Reproduce Expected behavior Judy should build correctly Screenshots A build log from my (currently private) Hydra instance shall be attached to this issue: Additional context This is another of my issues about cross-compiling. I discovered by setting up a (currently private) Hydra instance that tries to cross-compile things. Metadata I have tested it on my Hydra and on my laptop, and it's consistent between Nixpkgs revisions right now. Here's metadata from my laptop: system: host os: multi-user?: sandbox: version: channels(root): channels(kisik21): nixpkgs: Maintainer information:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Change:
substituteInPlace etc/firejail.config --replace  '# follow-symlink-as-user yes'  'follow-symlink-as-user no' <ins> # Fix the path to 'xdg-dbus-proxy' hardcoded in the 'common.h' file substituteInPlace src/include/common.h  --replace '/usr/bin/xdg-dbus-proxy' '${xdg-dbus-proxy}/bin/xdg-dbus-proxy' </ins> ''; preConfigure = ''

Discussion:
Describe the bug 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 system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs: Maintainer information:
Seems like updating to 0.9.64.4 is the way to go?
Can be closed?!
Change:
<ins> library ieee; use IEEE.STD_LOGIC_1164.all; use ieee.numeric_std.all; library STD; use STD.textio.all; entity tb is end tb; architecture beh of tb is component simple port ( CLK, RESET : in std_ulogic; DATA_OUT : out std_ulogic_vector(7 downto 0); DONE_OUT : out std_ulogic ); end component; signal data : std_ulogic_vector(7 downto 0) := "00100000"; signal clk : std_ulogic; signal RESET : std_ulogic := '0'; signal done : std_ulogic := '0'; signal cyclecount : integer := 0; constant cycle_time_c : time := 200 ms; constant maxcycles : integer := 100; begin simple1 : simple port map ( CLK => clk, RESET => RESET, DATA_OUT => data, DONE_OUT => done ); clk_process : process begin clk <= '0'; wait for cycle_time_c/2; clk <= '1'; wait for cycle_time_c/2; end process; count_process : process(CLK) begin if (CLK'event and CLK ='1') then if (RESET = '1') then cyclecount <= 0; else cyclecount <= cyclecount + 1; end if; end if; end process; test : process begin RESET <= '1'; wait until (clk'event and clk='1'); wait until (clk'event and clk='1'); RESET <= '0'; wait until (clk'event and clk='1'); for cyclecnt in 1 to maxcycles loop exit when done = '1'; wait until (clk'event and clk='1'); report integer'image(to_integer(unsigned(data))); end loop; wait until (clk'event and clk='1'); report "All tests passed." severity NOTE; wait; end process; end beh; </ins>

Discussion:
Describe the bug To Reproduce -env -i ghdl-llvm # or nix run ... -a Expected behavior ghdl compiles and runs the code Additional context uses LLVM as a backend to compile VHDL to a simulator executable for RTL simulation. It finally links its outputs using (via a call to gcc). The problem is, that in this linking step it also wants to link , which the linker can not find. However, in a everything works as intended. Even a and appending to NIX_LDPATH suffices. I tried various (combinations) of and friends and also , but never got this to work. I suspect that there is something in the setup hook of the nix-shell, but inspecting and comparing s didn't get me any further. Maybe someone could look into this or introduce me to the dark magic of and packaging compilers. (Looking at other compiler's .nix files also was a dead end for me.)
I marked this as stale due to inactivity. &rarr;
Change:
noip = callPackage ../tools/networking/noip { }; <del> nomad = callPackage ../applications/networking/cluster/nomad { buildGoPackage = buildGo112Package; }; </del> <ins> nomad = callPackage ../applications/networking/cluster/nomad { }; </ins> notable = callPackage ../applications/misc/notable { };

Discussion:
When building chromium through nixos-rebuild off of the latest nixpkgs master: Not sure what changed, I don't see any recent updates to heimdal or pthreads, but I may have missed something.
I updated nixpkgs and this issue seemed to disappear. I'll reopen if I encounter this again.
I got this today on master ():
Ah, I see (I assume because of patch dependencies). Testing with that commit reverted now.
It worked. Pushed to master.

it's supposed to be reachable via , from within emacs, but it is not. However, the program can find it, when run as
I misunderstood some emacs-related things. I'm not sure if the situation is perfect or not, but at least the manual I want is available at

We seem to have unpatched vulnerabilities (noticed by nixpkgs monitor):
The first one was explicitly claimed to be fixed in 2.21 NEWS, although the CVE entry claims that version still suffers from it.

Here's the error message: Here's the full log:
cc
My installation command was wrong. I had when I should have had
Change:
lupupy = callPackage ../development/python-modules/lupupy { }; <ins> lxmf= callPackage ../development/python-modules/lxmf { }; </ins> lxml = callPackage ../development/python-modules/lxml { inherit (pkgs) libxml2 libxslt zlib; };

Discussion:
Project description Reticulum is the cryptography-based networking stack for wide-area networks built on readily available hardware. It can operate even with very high latency and extremely low bandwidth. Reticulum allows you to build wide-area networks with off-the-shelf tools, and offers end-to-end encryption and connectivity, initiator anonymity, autoconfiguring cryptographically backed multi-hop transport, efficient addressing, unforgeable delivery acknowledgements and more. Reticulum is a complete networking stack, and does not need IP or higher layers, although it is easy to use IP (with TCP or UDP) as the underlying carrier for Reticulum. It is therefore trivial to tunnel Reticulum over the Internet or private IP networks. Having no dependencies on traditional networking stacks free up overhead that has been utilised to implement a networking stack built directly on cryptographic principles, allowing resilience and stable functionality in open and trustless networks. No kernel modules or drivers are required. Reticulum runs completely in userland, and can run on practically any system that runs Python 3. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin
Change:
<ins> { lib , stdenv , fetchFromGitLab , meson , ninja , pkg-config , python3Packages , vulkan-headers , vulkan-loader , shaderc , lcms2 , libGL , libX11 , libunwind , libdovi }: stdenv.mkDerivation rec { pname = "libplacebo"; version = "5.264.1"; src = fetchFromGitLab { domain = "code.videolan.org"; owner = "videolan"; repo = pname; rev = "v${version}"; hash = "sha256-YEefuEfJURi5/wswQKskA/J1UGzessQQkBpltJ0Spq8="; }; nativeBuildInputs = [ meson ninja pkg-config vulkan-headers python3Packages.jinja2 python3Packages.glad2 ]; buildInputs = [ vulkan-loader shaderc lcms2 libGL libX11 libunwind libdovi ]; mesonFlags = with lib; [ (mesonOption "vulkan-registry" "${vulkan-headers}/share/vulkan/registry/vk.xml") (mesonBool "demos" false) # Don't build and install the demo programs (mesonEnable "d3d11" false) # Disable the Direct3D 11 based renderer (mesonEnable "glslang" false) # rely on shaderc for GLSL compilation instead ] ++ optionals stdenv.isDarwin [ (mesonEnable "unwind" false) # libplacebo doesn’t build with `darwin.libunwind` ]; postPatch = '' substituteInPlace meson.build  --replace 'python_env.append' '#' ''; meta = with lib; { description = "Reusable library for GPU-accelerated video/image rendering primitives"; longDescription = '' Reusable library for GPU-accelerated image/view processing primitives and shaders, as well a batteries-included, extensible, high-quality rendering pipeline (similar to mpv's vo_gpu). Supports Vulkan, OpenGL and Metal (via MoltenVK). ''; homepage = "https://code.videolan.org/videolan/libplacebo"; changelog = "https://code.videolan.org/videolan/libplacebo/-/tags/v${version}"; license = licenses.lgpl21Plus; maintainers = with maintainers; [ primeos tadeokondrak ]; platforms = platforms.all; }; } </ins>

Discussion:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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.
Done here:
Change:
, # Shell code executed after the VM has finished. postVM ? "" <ins> , # Guest memory size memSize ? 1024 </ins> , # Copy the contents of the Nix store to the root of the image and # skip further setup. Incompatible with `contents`, # `installBootLoader` and `configFile`.

Discussion:
Building an Amazon AMI with zfs root fails with inside the vm getting an error trying to allocate memory partway through building the new store. It isn’t surprising that a zfs-using system needs more memory when doing intensive filesystem writes. Unfortunately I don't know how to adjust the config (other than globally in a nixpkgs fork) for how much memory to give the vm. $ nix-build -A amazonImageZfs.x8664-linux … error: reading directory '/nix/store/4l99mg8j2c3bqjlc10ncdfcq5vaazxb9-nixos-22.11pre130979.gfedcba/nixos/pkgs/tools/misc/tagref': Cannot allocate memory (the specific package or failure point varies a little on each run based on random timings and resource usage) system: host os: multi-user?: sandbox: version: channels(root): channels(dan): nixpkgs:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
"session optional ${pkgs.apparmor-pam}/lib/security/pam_apparmor.so order=user,group,default debug"} ${optionalString (cfg.enableKwallet) ("session optional ${pkgs.plasma5.kwallet-pam}/lib/security/pam_kwallet5.so" + <del> " kwalletd=${pkgs.libsForQt5.kwallet}/bin/kwalletd5")} </del> <ins> " kwalletd=${pkgs.libsForQt5.kwallet.bin}/bin/kwalletd5")} </ins> ''); };

Discussion:
Sometime between the 17.03 release and today, the pamkwallet5 module (which unlocks your KDE wallet using your login password when you authenticate via a display manager) quit working. Here's what I can find in syslog: The issue is probably just that pamkwallet5 is looking for the kwalletd5 binary in the wrong spot. Run NixOS with: Login to a graphical session and initialize kde wallet with the same password as your login password. Log out and back in. System: NixOS (Hummingbird) Nix version: 1.11.13 Nixpkgs version: Sandboxing enabled: true Kernel version: 4.12.7 (but it's the same under 4.9) My entire nixos config can be found here:
Change:
export DOXYGEN=${doxygen}/bin/doxygen export PATH="${wxGTK}/bin:$PATH" export SDL_CONFIG="${SDL.dev}/bin/sdl-config" <ins> export WAF=$PWD/bin/waf </ins> ${python.pythonOnBuildForHost.interpreter} build.py -v --use_syswx dox etg sip --nodoc build_py

Discussion:
Steps to reproduce the behavior: It looks like the was at 9 July 2024 at 4:10:47 am GMT+2. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
see
Change:
themes = recurseIntoAttrs (getPackagesWithPrefix "theme"); }; <del> thefuck = python3Packages.callPackage ../tools/misc/thefuck { }; </del> theme-sh = callPackage ../tools/misc/theme-sh { }; thiefmd = callPackage ../applications/editors/thiefmd { };

Discussion:
Steps to reproduce the behavior: nixpkgs-unstable thefuck Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Seems fixable by moving to an unstable rev
Also related
Same behavior here on MacOS using home-manager. Just a note that I'm on Python 3.12.3, so I'm not sure that the commit noted above will take this into consideration as that just adds support for 3.12-dev.
I'm currently on vacation, so a bit limited time. I guess our options are either pinning it to python11 until there's a release, moving to unstable or adding that commit as a patch.
This happened due to recent shift to Python 3.12 in Nixpkgs. Mind backporting it then?
Change:
<ins> { "url": "https://github.com/nvim-neorg/tree-sitter-norg-meta", "rev": "a479d1ca05848d0b51dd25bc9f71a17e0108b240", "date": "2023-05-28T19:01:42+02:00", "path": "/nix/store/7yp5rzpmdvyhhl38brhz0vl3gd9qv03y-tree-sitter-norg-meta", "sha256": "1vvl39m41wgsq7xkfi523zx6nza03dkzgk6izc39igmwx5hsdl7f", "hash": "sha256-7tCmYem8vpgG+9HM92cbQH1r+h+iRDf7wfrxQGoadO8=", "fetchLFS": false, "fetchSubmodules": false, "deepClone": false, "leaveDotGit": false } </ins>

Discussion:
Project description <!-- Describe the project a little: --I've recently watched the videos on norg and found the plugin very code. At some point though I had an error because my system was missing this treesitter grammar: It doesn't seem packaged yet (I checked unstable). Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ... Priorities Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
let defaultOverrides = [ (self: super: { <del> flask = super.flask.overridePythonAttrs (oldAttrs: rec { version = "1.1.2"; pname = "Flask"; </del> <ins> wtforms = super.wtforms.overridePythonAttrs (oldAttrs: rec { version = "2.3.1"; pname = "WTForms"; </ins> src = super.fetchPypi { inherit pname version; <del> sha256 = "sha256-Tvoa4tfJhlr0iYbeiuuFBL8yx/PW/ck1PTSyH0sScGA="; </del> <ins> sha256 = "sha256-hhoTs65SHWcA2sOydxlwvTVKY7pwQ+zDqCtSiFlqGXI="; </ins> }; <del> checkInputs = [ self.pytest ]; propagatedBuildInputs = with self; [ itsdangerous click werkzeug jinja2 ]; doCheck = false; }); }) (self: super: { flask_login = super.flask_login.overridePythonAttrs (oldAttrs: rec { pname = "Flask"; version = "0.5.0"; src = fetchPypi { inherit pname version; sha256 = "6d33aef15b5bcead780acc339464aae8a6e28f13c90d8b1cf9de8b549d1c0b4b"; }; </del> doCheck = false; }); })

Discussion:
, CVSSv3=4.3 (nixos-21.11) archivy is vulnerable to Cross-Site Request Forgery (CSRF) Scanned versions: nixos-21.11: . Cc
Change:
<del> { stdenv, lib, fetchurl, dpkg, patchelf, qt5, libXtst, libXext, libX11, makeWrapper, libXScrnSaver }: </del> <ins> { stdenv, lib, fetchurl, dpkg, patchelf, qt5, libXtst, libXext, libX11, mkDerivation, makeWrapper, libXScrnSaver }: </ins> let src = if stdenv.hostPlatform.system == "i686-linux" then fetchurl { name = "rescuetime-installer.deb"; url = "https://www.rescuetime.com/installers/rescuetime_current_i386.deb"; <del> sha256 = "03bky9vja7fijz45n44b6gawd6q8yd30nx6nya9lqdlxd1bkqmji"; </del> <ins> sha256 = "0mw8dh9z7pqan0yrhycmv39h5c1sc4mbw5l02cfnn17cy75xdiay"; </ins> } else fetchurl { name = "rescuetime-installer.deb"; url = "https://www.rescuetime.com/installers/rescuetime_current_amd64.deb"; <del> sha256 = "03bky9vja7fijz45n44b6gawd6q8yd30nx6nya9lqdlxd1bkqmji"; </del> <ins> sha256 = "1a6pc8vi2ab721kzyhvg6bmw24dr85dgmx2m9j9vbf3jyr85fv10"; </ins> }; <del> in stdenv.mkDerivation { </del> <ins> in mkDerivation { </ins> # https://www.rescuetime.com/updates/linux_release_notes.html <del> name = "rescuetime-2.14.3.1"; </del> <ins> name = "rescuetime-2.14.5.2"; </ins> inherit src; <del> buildInputs = [ dpkg makeWrapper ]; </del> <ins> nativeBuildInputs = [ dpkg ]; </ins> # avoid https://github.com/NixOS/patchelf/issues/99 dontStrip = true; unpackPhase = ''

Discussion:
Describe the bug To Reproduce Steps to reproduce the behavior: 19.09 channel rescuetime to start it Expected behavior The application should start without problems. Additional context Related Metadata Maintainer information:
Change:
meta.homepage = "https://github.com/ludovicchabant/vim-gutentags/"; }; <ins> vim-habamax = buildVimPlugin { pname = "vim-habamax"; version = "2024-01-22"; src = fetchFromGitHub { owner = "habamax"; repo = "vim-habamax"; rev = "8b4e045b711c7e90235a601ba2a923cdfacb2f46"; sha256 = "02973qssq450d4411zjscsjvwz4fc2lpqvimah06k87skp8inp47"; }; meta.homepage = "https://github.com/habamax/vim-habamax/"; }; </ins> vim-hardtime = buildVimPlugin { pname = "vim-hardtime"; version = "2022-05-06";

Discussion:
Project description The habamax theme for vim. Metadata homepage URL: source URL: license: None platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
# 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 = {

Discussion:
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…