jiebi/CodeConvo huggingface dataset:
Code change:
<ins> --- a/llm/generate/gen_common.sh +++ b/llm/generate/gen_common.sh @@ -86,7 +89,7 @@ cmake -S ${LLAMACPP_DIR} -B ${BUILD_DIR} ${CMAKE_DEFS} cmake --build ${BUILD_DIR} ${CMAKE_TARGETS} -j8 mkdir -p ${BUILD_DIR}/lib/ -    g++ -fPIC -g -shared -o ${BUILD_DIR}/lib/libext_server.${LIB_EXT}  +    $CXX -fPIC -g -shared -o ${BUILD_DIR}/lib/libext_server.${LIB_EXT}  ${GCC_ARCH}  ${WHOLE_ARCHIVE} ${BUILD_DIR}/examples/server/libext_server.a ${NO_WHOLE_ARCHIVE}  ${BUILD_DIR}/common/libcommon.a  </ins>

Related discussion:
text: Package name: ollama Latest released version: 0.1.20 <!-- Search your package here: --- Current version on the unstable channel: 0.1.17 Current version on the stable/release channel: 0.1.7 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
20 was released.[^1] :tada: Had a quick look into the source changes. Seems that patching is required because of the integration of ROCm. [^1]:
I modified the title :-)
21 is going to be released very soon.
I opened
update: 0.1.22 is the latest version.
Seems update can be problematic. I've tried manually download and executing new ollama and encountered a lot of issues connected with ROCM libraries. After adding I've got it to state where it crushes: But before adding it seems also miss new version of because it was asking for but current unstable version have CPU works fine without mentioned ROCM packages.
This appears to have been resolved by . Reopen if it's not.
Code change:
{ lib, stdenv, fetchurl, pkg-config, zlib, kmod, which <ins> , hwdata </ins> , static ? stdenv.hostPlatform.isStatic , darwin ? null }:

Related discussion:
text: Describe the bug pciutils is using a really old file which doesn't include any definitions for AMD Radeon 6800 XT cards. When running you get the following output If you get a newer version of the file from https://pci- which update-pciids script in package normally updates (but is disabled in nix package). You get the following: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(wil): nixpkgs: Maintainer information:
Should also mention when running strace on lspci it reads the file from /nix/store/464020m9r6mhsivgp9v1bhkyzz5pa0gq-pciutils- and not from hwdata like I originally thought.
Would it make sense to make lspci depend on hwdata and then use from hwdata? cc'ing (who is listed as shadow maintainer of pciutils)
Hmm, makes sense. Except that seems to be in significantly more closures than , so depending on the extra 6+ MB of other data seems significant. Perhaps make put it into a separate output? Or could just copy it as a quick work-around (that's free for people with )
Oh, we can't "just" make multi-output, as it's a fixed-output derivation, but we could fake it through multiple derivations. Maybe just the work-around for simplicity then?
I think the work-around is actually pretty sensible. I'll prepare a pull request :-) Update: Did so, . Once both and are merged, our issue should be resolved.
Thanks for fixing that :). I tried your two updates on my machine and it appears to be resolved. Closing the issue out. Now we just wait for this to get into unstable :).
Code change:
which # Needed by gdialog, including in the steam-runtime perl <del> ] ++ lib.optional withJava jdk ++ lib.optional withPrimus (primus.override { stdenv = overrideInStdenv stdenv [ useOldCXXAbi ]; stdenv_i686 = overrideInStdenv pkgsi686Linux.stdenv [ useOldCXXAbi ]; }) ; </del> <ins> ] ++ lib.optional withJava jdk ++ lib.optional withPrimus (primus.override { stdenv = overrideInStdenv stdenv [ useOldCXXAbi ]; stdenv_i686 = overrideInStdenv pkgsi686Linux.stdenv [ useOldCXXAbi ]; }); </ins> <del> multiPkgs = pkgs: with pkgs; [ </del> <ins> multiPkgs = pkgs: with pkgs; [ </ins> # These are required by steam with proper errors xlibs.libXcomposite xlibs.libXtst

Related discussion:
text: This weekend I tried these games, all deadlocked in the menu or character selection. Nyheim Oh...Sir! The Insult Simulator Reigns Unturned (free to play) You don't have to be worried to waste money in case you want to test a game. I have had no problem when requesting refunds, just go to I have played these games and found no issues with them: Dota 2 Counter-Strike TIS-100 World of goo Faster Than Light You Must Build a Boat Risk of Rain System: (NixOS: , Ubuntu/Fedora: , ...) 03pre99759. (Gorilla) Nix version: (run ) nix-env (Nix) 1.11.6 Nixpkgs version: (run ) "17.03pre99759." Integrated graphics card, 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
This is normal with steam on nixos unfortunately. There are many steam games that don't work for various reasons, unfortunately many linux steam game developers only make sure their games run on ubuntu and don't really care about relying only on dependencies from the steam runtime. Some games don't play nice with certain graphics cards or drivers as well. If you want to get a particular game working (I can list 150 games that work under nixos with nvidia card and drivers at least) then you'll need to do some work, or at least post any relevant logs from the game/steam so people can actually help you solve the problem. That is assuming that they own the game. :)
There's a slowly-growing list of extra dependencies in the Steam package. If you can figure out what's missing, you can add it there; e.g. as in
I don't have enough motivation to actually buy games for the sole purpose of fixing them and then refunding, sorry. Nevertheless, I'm happy to help if you can post logs and/or s -- those two are the most helpful for determining FHS-related problems.
Code change:
<del> { stdenv, fetchurl, pkgconfig, glib, libintl }: </del> <ins> { stdenv, fetchurl, fetchpatch, pkgconfig, glib, libintl }: </ins> with stdenv.lib;

Related discussion:
text: I saw the following during a rebuild: Error in file "/nix/store/vwd5hb2n6m7nwqijlz0rsmn5x6fpmlhw-system-": "font/ttf" is an invalid MIME type ("font" is an unregistered media type) Error in file "/nix/store/vwd5hb2n6m7nwqijlz0rsmn5x6fpmlhw-system-": "font/ttf" is an invalid MIME type ("font" is an unregistered media type) Error in file "/nix/store/vwd5hb2n6m7nwqijlz0rsmn5x6fpmlhw-system-": "font/opentype" is an invalid MIME type ("font" is an unregistered media type) Error in file "/nix/store/vwd5hb2n6m7nwqijlz0rsmn5x6fpmlhw-system-": "font/collection" is an invalid MIME type ("font" is an unregistered media type) Unknown system: host os: multi-user?: sandbox: version: nixpkgs:
I think we just need to update , c.f.
Ah, it seems that upstream has not released a version with the fixed commit in. The last tagged release was , they haven't tagged anything with the fix commit in. We could build from their git head, I guess, although I'm reluctant to do so. Perhaps complain ?
If the commit applies as a patch that would also be fine.
I'm still having this. had it for build and build (separately). build
Code change:
owner = "tud-zih-energy"; repo = "FIRESTARTER"; rev = "v${version}"; <del> sha256 = "161mg0h1hvp6bxfjdhyfqrljvphys896mfd36254rbgzxm38ibi7"; </del> <ins> sha256 = "0zqfqb7hf48z39g1qhbl1iraf8rz4d629h1q6ikizckpzfq23kd0"; </ins> }; nativeBuildInputs = [ python3 ];

Related discussion:
text: Describe the bug I don't know if we should just update it or not. To Reproduce Steps to reproduce the behavior: on master Expected behavior Screenshots Additional context Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(bbigras): channels(root): nixpkgs: Maintainer information:
I can reproduce the issue locally It used to build previously The current is not in the Hydra cache because was never built by Hydra, so, unless someone else has the , we can't compare Upstream tag doesn't appear to be updated, git repo doesn't use export-subst It is not clear to me what has happened here.
Dear all, the tag v1.7.4 has been changed after October 2019. It was not published for long as it involuntarily got into a commit. There have been no public releases for v1.7.4 marked on Github or our the FIRESTARTER Website as of October 2019.
Thanks everyone for the help. :heart:
Code change:
, wrapQtAppsHook , extra-cmake-modules , qtbase <ins> , qtwayland </ins> , qtsvg , qtimageformats , qt5compat

Related discussion:
text: low priority qt6.qtdeclarative is a large package, so it should be excluded for non-GUI qt apps () currently, when i build a package with and empty buildInputs, it pulls qt6.qtwayland qt6.qtdeclarative qt6.qtshadertools the problem is wrapQtAppsHook and its deps and qtwayland pulls qtdeclarative the problem is fixed by removing from deps wrapQtAppsHook should use only the declared buildInputs disabling wrapQtAppsHook (dontWrapQtApps = true) is no option, as also CLI qt apps need the qt wrapper qtwayland is there, so that users dont need to add it to buildInputs assuming that all qt apps are GUI apps im in favor of making this consistent with cmake so that all GUI apps must add qtwayland to buildInputs CLI qt app: GUI qt app: since cc
I'm in favour of this change, but the proportion of qt cli app night be relatively small, and it's not immediately clear that qtwayland should be if the build log yields Qt6::Widgets is missing.
Actually we are abusing qtwayland as a shortcut to bringing in qtdeclarative, this should be fixed too.
we could patch the cmake message to "please add qtdeclarative to your propagatedBuildInputs" the alternative would be to add a flag, but thats more obscure than buildInputs
Adding the lines to nixpkgs manual is sufficient.
By the way, is not only needed to pull in , but it's required for all GUI apps so that they work seamlessly on X11 or Wayland.
Code change:
echo "Adding contents..." for item in ${toString contents}; do echo "Adding $item..." <del> rsync -a $item/ layer/ </del> <ins> rsync -ak $item/ layer/ </ins> done '';

Related discussion:
text: dockerTools.buildImage fails with: System: 17.03pre95306. (Gorilla) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: "17.03pre95306."
Code change:
--bash completion/bash-completion ''; <del> nativeBuildInputs = [ installShellFiles ]; </del> <ins> nativeBuildInputs = [ installShellFiles ]; </ins> <del> buildInputs = [ babel ]; </del> <ins> buildInputs = [ babel ]; </ins> propagatedBuildInputs = [ androguard <ins> appdirs </ins> clint defusedxml gitpython libcloud mwclient <ins> oscrypto </ins> paramiko pillow pyasn1

Related discussion:
text: Steps to reproduce the behavior: build .#fdroidserver Git bisect predictably found the culprit as , so it is related to the Python 3.12 upgrade. I suspect that all setuptools-based modules are broken; e.g. also stops building. Interestingly, built before, but not after. Not sure what that implies. (Originally I had notified the Python team, but I removed them from this list because I am suspecting this regression may not be the result of any problem with the version flip itself, but the broken packages instead. Sorry.) Notifying from fdroidserver maintainers. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
Path to the unix socket file on which to accept FastCGI requests. <note><para>This option is read-only and managed by NixOS.</para></note> ''; <ins> example = "${runtimeDir}/<name>.sock"; </ins> }; listen = mkOption {

Related discussion:
text: Describe the bug The description of is: Path to the unix socket file on which to accept FastCGI requests. This option is read-only and managed by NixOS. So i can't set it. But how can i figure out how the socket path is now? Please add an example to the description! To Reproduce Steps to reproduce the behavior: option desciption Expected behavior Useful description. Metadata same in 19.09 and 20.03 Maintainer information:
The point of the option is that you don't need to find out, just reference it. That being said I agree with your issue and it would be helpful to set an example
The point of the option is that you don't need to find out, just reference it. Sure, that works in but i have that path explicitely in my webserver config which is next to the content, e.g. . For reference: The path is actually as i set it before: So i can just remove the option from my .
Code change:
{ stdenv, fetchurl, xdg_utils, dpkg, makeWrapper, autoPatchelfHook <del> , libXtst, libXScrnSaver, gtk3, nss, alsaLib, udev, libnotify </del> <ins> , libXtst, libXScrnSaver, gtk3, nss, alsaLib, udev, libnotify, wrapGAppsHook </ins> }: let

Related discussion:
text: Describe the bug A clear and concise description of what the bug is. Rambox apps cause rambox to crash when attempting to upload a file. It gives the message: To Reproduce Steps to reproduce the behavior: rambox rambox in terminal any app that has file upload functionality (I tested Google Messages, Element, and Slack) to upload file Expected behavior Rambox apps should be able to upload files from filesystem Additional context I've seen from browsing other issues that this has been solved before for riot-desktop at first by adding gsettings schema to the package wrapper but currently fixed by using in electron. However, for some reason this did not fix the issue in Rambox. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. these paths will be fetched (0.05 MiB download, 0.28 MiB unpacked): /nix/store/d43v6bx7r6fcaq3fbbfd5mwh1f5s7rmg-bash-interactive-4.4-p23-dev copying path '/nix/store/d43v6bx7r6fcaq3fbbfd5mwh1f5s7rmg-bash-interactive-4.4-p23-dev' from ''... system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Add wrapGAppsHook to
Code change:
{ meta = { <del> maintainers = teams.freedesktop.members; </del> <ins> maintainers = teams.freedesktop.members ++ [ lib.maintainers.janik ]; </ins> }; ###### interface

Related discussion:
text: Describe the bug NetworkManager is a particularly important component and we don't have any tests for it that could block a channel advance. In particular, a change can happen on nixos-unstable leaving users without functioning networking, and while rollbacks are possible it isn't an excuse to allow that to reach production systems. NixOS doesn't produce either. Manual testing is also cumbersome if we want to make a new stable release. Upstream NetworkManager does have some integration testing but obviously not useful to us. I think to start, if we at least had a test that verifies the services start without issues would be great.
Agreed. While developing tests for the multipath TCP module I was surprised to see no networkmanager module. I had some difficulties with the nixos test infrastructure at first because the test infra will by default install a slirp interface () and it messed up the interface naming. Like I would clear but interfaces would still be named starting from instead of . Just thought I would mention it in case the brave soul writing the test is interested in multihoming. (but that's more a concern I have with the test infra).
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 . 3. Ask on the on .
Bleh.
I marked this as stale due to inactivity. &rarr;
consequences of our inactions
Code change:
++ optional langFortran ../gfortran-driving.patch ++ optional (targetPlatform.libc == "musl" && targetPlatform.isPower) ../ppc-musl.patch ++ optional (targetPlatform.libc == "musl") ../libgomp-dont-force-initial-exec.patch <del> ++ optional (!crossStageStatic && targetPlatform.isMinGW) (fetchpatch { url = "https://raw.githubusercontent.com/lhmouse/MINGW-packages/${import ../common/mfcgthreads-patches-repo.nix}/mingw-w64-gcc-git/9000-gcc-${majorVersion}-branch-Added-mcf-thread-model-support-from-mcfgthread.patch"; sha256 = "1nyjnshpq5gbcbbpfv27hy4ajvycmgkpiabkjlxnnrnq1d99k1ay"; }); </del> <ins> # Obtain latest patch with ../update-mcfgthread-patches.sh ++ optional (!crossStageStatic && targetPlatform.isMinGW) ./Added-mcf-thread-model-support-from-mcfgthread.patch; </ins> /* Cross-gcc settings (build == host != target) */ crossMingw = targetPlatform != hostPlatform && targetPlatform.libc == "msvcrt";

Related discussion:
text: Describe the bug is when building for MinGW, however an equivalent GCC 10 patch file doesn't exist. I tried looking for a GCC 10 patch on the master branch of , but the folder that contained the patches no longer exists. GCC9 is still currently the default on master, but this will break everything under MinGW the next time staging-next is merged to master. See Support for was originally in To Reproduce Steps to reproduce the behavior: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(kira): nixpkgs: Maintainer information:
It has been moved to to upstream migration. Neither of these repos is stable; their master branches are constantly rebased on upstream and force-pushed.
Code change:
homepage = "https://libdatachannel.org/"; license = with licenses; [ mpl20 ]; maintainers = with maintainers; [ erdnaxe ]; <del> platforms = platforms.linux; </del> <ins> platforms = platforms.linux ++ platforms.darwin; </ins> }; }

Related discussion:
text: HTTP Toolkit is an open-source tool for debugging, testing and building with HTTP(S) on Windows, Linux & Mac. Metadata homepage URL: source URL: license: AGPL v3.0 platforms: linux, darwin
Sorry, wasn't able to get it working. The httptoolkit-server is the difficult part. I tried building from source, however one of the dependencies tries to npm install more stuff in prebuild, so it wasn't building properly. I tried packaging the prebuilt binary but it's trying to do some auto updating and also package node with itself. I could have patched this when building from source, however the prebuilt one is minified & obfuscated so I couldn't do that.
Have you a branch to continue the work ?
+1
I've started a small bounty of 20$ on this: It's not much but it would be great to have this tool on nix!
I made another attempt at packaging this and I'm pretty close to getting httptoolkit-server to compile from source. This should help with patching out stuff, since we can do it before it gets obfuscated.
if anyone needs to run this on nix the appimage provided by HttpToolkit works pretty well on nix with no extra dependencies. See and then Would still be great to have this as a nix package though.
Hey thanks for adding this! You can claim the gitpay bounty here: (I've tried to find your email to invite you but didn't have much luck) or email me at
Sent you an email,
Code change:
nativeBuildInputs = lib.optionals stdenv.isDarwin [ cctools fixDarwinDylibNames <ins> ] ++ lib.optionals (stdenv.isDarwin && stdenv.isAarch64) [ autoSignDarwinBinariesHook </ins> ]; dontConfigure = true; <del> buildPhase = let ccc = if stdenv.isDarwin then "ccc.osx" else "ccc"; in '' runHook preBuild </del> <ins> buildPhase = let ccc = if stdenv.isDarwin then "ccc.osx" else "ccc"; in '' runHook preBuild </ins> <del> (cd lpsolve55 && bash -x -e ${ccc}) (cd lp_solve  && bash -x -e ${ccc}) </del> <ins> (cd lpsolve55 && bash -x -e ${ccc}) (cd lp_solve  && bash -x -e ${ccc}) </ins> <del> runHook postBuild ''; </del> <ins> runHook postBuild ''; </ins> installPhase = '' runHook preInstall

Related discussion:
text: Steps to reproduce the behavior:
I don't have an M1 to test
Oh, it suffices to use . I'll open a pull request.
Code change:
<ins> { lib, alsa-lib, callPackage, cmake, ffmpeg, fribidi, game-music-emu, libXdmcp, libXv, libass, libcddb, libcdio, libpulseaudio, libsidplayfp, libva, libxcb, ninja, pkg-config, qt5, qt6, stdenv, taglib, vulkan-headers, vulkan-tools, # Configurable options qtVersion ? "6", # Can be 5 or 6 }: let sources = callPackage ./sources.nix { }; in assert lib.elem qtVersion [ "5" "6" ]; stdenv.mkDerivation (finalAttrs: { pname = sources.qmplay2.pname + "-qt" + qtVersion; inherit (sources.qmplay2) version src; postPatch = '' pushd src cp -va ${sources.qmvk.src}/* qmvk/ chmod --recursive 744 qmvk popd ''; nativeBuildInputs = [ cmake ninja pkg-config ] ++ lib.optionals (qtVersion == "6") [ qt6.wrapQtAppsHook ] ++ lib.optionals (qtVersion == "5") [ qt5.wrapQtAppsHook ]; buildInputs = [ alsa-lib ffmpeg fribidi game-music-emu libXdmcp libXv libass libcddb libcdio libpulseaudio libsidplayfp libva libxcb taglib vulkan-headers vulkan-tools ] ++ lib.optionals (qtVersion == "6") [ qt6.qt5compat qt6.qtbase qt6.qtsvg qt6.qttools ] ++ lib.optionals (qtVersion == "5") [ qt5.qtbase qt5.qttools ]; strictDeps = true; # Because we think it is better to use only lowercase letters! # But sometimes we come across case-insensitive filesystems... postInstall = '' [ -e $out/bin/qmplay2 ] || ln -s $out/bin/QMPlay2 $out/bin/qmplay2 ''; passthru = { inherit sources; }; meta = { homepage = "https://github.com/zaps166/QMPlay2/"; description = "Qt-based Multimedia player"; longDescription = '' QMPlay2 is a video and audio player. It can play all formats supported by FFmpeg and libmodplug (including J2B and SFX). It also supports Audio CD, raw files, Rayman 2 music, and chiptunes. It also contains YouTube and MyFreeMP3 browser. ''; license = lib.licenses.lgpl3Plus; mainProgram = "qmplay2"; maintainers = with lib.maintainers; [ AndersonTorres kashw2 ]; platforms = lib.platforms.linux; }; }) </ins>

Related discussion:
text: 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.