jiebi/CodeConvo huggingface dataset:
Code change:
, fetchurl , makeWrapper , makeDesktopItem <del> # sweethome3d 6.5.2 does not yet fully build&run with jdk 9 and later? , jdk8 , jre8 </del> <ins> , jdk </ins> , ant , gtk3 , gsettings-desktop-schemas

Related discussion:
text: For me, was needed (with patch). I also needed . and didn't seem needed (or give noticable changes).
Code change:
sha256 = "0g89al4kwfbx1l3zjddgb9ay4mhr7zk0ndchca3sm1vq2j47nf4l"; }; <ins> # This patch is required for version 2.2.1. As the patch is already part of # upstream master, it will be incorporated into the next release. The patch # fixes a (well-justified) compiler warning which breaks the build because # we compile with -Werror. patches = [ (fetchpatch { url = "https://github.com/Nuand/bladeRF/commit/163425d48a3b7d8c100d7295220d3648c050d0dd.patch"; sha256 = "1swsymlyxm3yk2k8l71z1fv0a5k2rmab02f0c7xkrvk683mq6yxw"; }) ]; </ins> nativeBuildInputs = [ pkgconfig ]; # ncurses used due to https://github.com/Nuand/bladeRF/blob/ab4fc672c8bab4f8be34e8917d3f241b1d52d0b8/host/utilities/bladeRF-cli/CMakeLists.txt#L208 buildInputs = [ cmake git doxygen help2man tecla libusb1 ]

Related discussion:
text: Describe the bug libbladeRF fails to build on the nixos-unstable channel and latest master: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Cannot reproduce this in master. I am on . Was this fixed in ?
I have just tried on , here is a full log:
Can also confirm that the build fails on .
This appears to me a genuine error in the source. Live bladerf1.c:841 (and also bladerf2.c:283) reference , but it should be . With , we stop the build on purpose. Luckily the typo is not of further consequence, since both values are numerically the same (both zero). I will try to report this to upstream.
Oh nice, this has already been fixed in upstream master (in from last May to be precise), but there isn't yet a new release containing a fix. I'll prepare a pull request cherrypicking this patch. Be aware though that I cannot test libbladeRF (in fact I don't even know what it is about :-)).
maybe also add . This options is meant for development where there is control over the compiler, but in nixpkgs we want to update gcc without breaking half the packages due to warnings.
I see, thank you for the suggestion! Generally I'm in favor of , but your argument is quite reasonable. I'll force-push in a second.
Code change:
# code refactoring of bcachefs-tools broke reading passphrases from stdin (vs. terminal) # upstream issue https://github.com/koverstreet/bcachefs-tools/issues/261 ./fix-encrypted-boot.patch <ins> # https://github.com/koverstreet/bcachefs-tools/pull/305 (fetchpatch { name = "use-ar-var-in-makefile.patch"; url = "https://github.com/koverstreet/bcachefs-tools/commit/91e67ab2bd48fa135a1f5109b23899a4f1019a03.patch"; sha256 = "sha256-nB4Tgcwa8eeasIDQ4rrYORie/X8LMuCSRi+WJNw+R/U="; }) </ins> ]; <ins> postPatch = '' substituteInPlace Makefile  --replace-fail "target/release/bcachefs" "target/${stdenv.hostPlatform.rust.rustcTargetSpec}/release/bcachefs" ''; </ins> preCheck = lib.optionalString (!fuseSupport) '' rm tests/test_fuse.py '';

Related discussion:
text: This is . Trying to build bcachefs-tools` for an aarch64-linux from x86_64-linux produces: I think comes from binutils. Adding binutils to nativeBuildInputs wasn't enough to fix it.
It's using a non-prefixed version of , it should instead be using
And after that we need to pass something like to cargo (or maybe directly to rustc?) somewhere. And we're spoiled for choice here: from in the Makefile to and env variables to maybe even .
I was able to fix this partially with this diff: That fixed the issue but seems like our libraries are incompatible? <details</details
Something has to be substituted in the source because ar is hardcoded
Applying that patch and adding The build now fails at
command encounters an error? Weird.
The built file is in instead of
Code change:
--prefix LD_LIBRARY_PATH : ${libPath} ''; <del> postInstall = '' </del> <ins> postInstall = lib.optionalString stdenv.isDarwin '' mkdir -p $out/Applications cp -r extra/osx/Neovide.app $out/Applications ln -s $out/bin $out/Applications/Neovide.app/Contents/MacOS '' + lib.optionalString stdenv.isLinux '' </ins> for n in 16x16 32x32 48x48 256x256; do install -m444 -D "assets/neovide-$n.png"  "$out/share/icons/hicolor/$n/apps/neovide.png"

Related discussion:
text: On aarch64-darwin, while neovide does build and install successfully and I can launch it from the terminal, there is no app bundle that can be found in finder to launch neovide from there or pin it to the dock to launch from. Once opened the global menu calls it .neovide-unwrapped and the icon in the dock is a blank white page as a generic icon. I can only assume that once is fixed, that this will also be applicable to x86_64-darwin Steps to reproduce the behavior: neovide as either a system app in nix-darwin or a user app in home-manager on aarch64-darwin An app bundle name that will be linked into or depending on and usage I'd like to point out that the global menu title is .neovide-unwrapped to for sure indicate that this is the nix neovide and not the homebrew neovide ! ! <!-- 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]:
Following PR MacOS app information a few days ago: We can install the files with next release of neovide.
Code change:
buildCommand = "sed s/dot_root/agroot/g ${raw_patch} > $out"; }; # 2.42 has the patch included <del> patches = optional (lib.versionOlder version "2.42") patchToUse; </del> <ins> patches = optional (lib.versionOlder version "2.42") patchToUse ++ optionals (lib.versionOlder version "2.46.0") [ (fetchpatch { name = "CVE-2020-18032.patch"; url = "https://gitlab.com/graphviz/graphviz/-/commit/784411ca3655c80da0f6025ab20634b2a6ff696b.patch"; sha256 = "1nkw9ism8lkfvxsp5fh95i2l5s5cbjsidbb3g1kjfv10rxkyb41m"; }) ]; </ins> in stdenv.mkDerivation {

Related discussion:
text: , CVSSv3=7.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
09 is still vulnerable
NixOS 20.09 is EOL, so this issue isn't actionable anymore.
Code change:
buildCommand = "sed s/dot_root/agroot/g ${raw_patch} > $out"; }; # 2.42 has the patch included <del> patches = optional (lib.versionOlder version "2.42") patchToUse; </del> <ins> patches = optional (lib.versionOlder version "2.42") patchToUse ++ optionals (lib.versionOlder version "2.46.0") [ (fetchpatch { name = "CVE-2020-18032.patch"; url = "https://gitlab.com/graphviz/graphviz/-/commit/784411ca3655c80da0f6025ab20634b2a6ff696b.patch"; sha256 = "1nkw9ism8lkfvxsp5fh95i2l5s5cbjsidbb3g1kjfv10rxkyb41m"; }) ]; </ins> in stdenv.mkDerivation {

Related discussion:
text: , CVSSv3=7.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
09 is still vulnerable
09 is EOL
Code change:
# backends , enableDeckjsBackend ? false , enableOdfBackend ? false <ins> # java is problematic on some platforms, where it is unfree , enableJava ? true </ins> }: assert enableStandardFeatures ->

Related discussion:
text: Since is provided by the non-free on aarch64, I'm not able to install asciidoc-full or any software that requires it to create e.g. the man pages. Can we make an option different from ? /cc
Making new granular options is fine, but I think enableStandardFeatures should still include java. (Or else the option is dishonest.) Alternatively, can we switch to openjdk (assuming that works on aarch64)?
It was just recently changed to in I'm fine with granular options, even though it will be quite some work to make packages not use anymore.
Oh, so this problem is due to licensing, not wanting to use non-free software? I didn't pick up on that earlier. How about adding a disableJava option, that has priority over enableStandardFeatures? Hm, this feels like a local solution to a global problem.
is a good idea! What do you think should be the default?
If enableStandardFeatures is true, you should get java. Setting disableJava then enables standard features except those requiring java. I'm not sure if doing this (per package) is a good idea though. Isn't this the start of a new whack-a-mole game?
Yes, it's certainly not a perfect solution, but I can then use an overlay which sets for . Alternatively, we could enable Java for x86 only by default.
Perhaps it would be less confusing to have so the additive condition is positive.
Code change:
ec2-config = (handleTestOn ["x86_64-linux"] ./ec2.nix {}).boot-ec2-config or {}; ec2-nixops = (handleTestOn ["x86_64-linux"] ./ec2.nix {}).boot-ec2-nixops or {}; ecryptfs = handleTest ./ecryptfs.nix {}; <ins> fscrypt = handleTest ./fscrypt.nix {}; </ins> ejabberd = handleTest ./xmpp/ejabberd.nix {}; elk = handleTestOn ["x86_64-linux"] ./elk.nix {}; emacs-daemon = handleTest ./emacs-daemon.nix {};

Related discussion:
text: I would like to use to encrypt my home directory. is already packaged (as , for some reason) What's missing is the PAM setup (). Given that exists for EcryptFS, I would like to request support for via the option, or something similar. I am aware that EcryptFS is available, to achieve the same goals, however it seems to be considered deprecated by other distributions (, ) and has some which I am not comfortable with.
This is just to say hi and to share that I too am interested in this feature
I marked this as stale due to inactivity. &rarr;
Code change:
]; </programlisting> </para> <para> <del> You can build custom PostgreSQL-with-plugins (to be used outside of NixOS) using function <literal>.withPackages</literal>. For example, creating a custom PostgreSQL package in an overlay can look like: </del> <ins> You can build custom PostgreSQL-with-plugins (to be used outside of NixOS) using function <literal>.withPackages</literal>. For example, creating a custom PostgreSQL package in an overlay can look like: </ins> <programlisting> self: super: { postgresql_custom = self.postgresql_11.withPackages (ps: [

Related discussion:
text: to newer version to different directory as under postgresql user Output I get:
The NixOS service module for PostgreSQL, for some unfathomable reason, initializes new databases using a non-standard superuser role name ( instead of ). This makes it a nightmare to get to work right, so forget that. Instead: back to your old version of postgresql root, dump your entire database to a file somewhere: to the new version of postgresql root, read in the database dump: (you'll likely see an error go by about the role already existing, you can ignore this) For good measure I went and tested this upgrading a 9.2 database to 9.4 under NixOS, worked fine, the applications using it continued on as normal after the import. That said, the real issue here is: why are we initializing databases using a non-standard install / superuser role name?
cc
See regarding the superuser role name.
Shouldn't we switch the default user to "postgres" on new databases and keep the "root" account around for existing-ones ? See
I strongly agree we should switch the default superuser to . Currently, it seems impossible to use to upgrade postgresql databases due to NixOS using the superuser: simply refuses to run as root.
The approach given by above doesn't work for me:
I can submit the change as a PR but don't use postgresql and it needs testing. Feel free to steal it and do the upgrade process with it.
pgdumpall tends to e pretty useless if you database isn't tiny_ :(
that would be a good start :)
there you go :)
FYI: I've just tested migrating 9.2 to 9.6 using and it works flawlessly.
Ok, I think I found out why wasn't working for me, like I mentioned in It seems to be due to this line in the Hydra module: If I change the mapping to then the command works fine. But I'm not exactly sure what are the implications of doing this, or why was mapped to in the first place...
In case someone runs into the same issue as me, I am documenting the procedure I used to upgrade a PostgreSQL database that was being used (only) for Hydra.
Code change:
]; </programlisting> </para> <para> <del> You can build custom PostgreSQL-with-plugins (to be used outside of NixOS) using function <literal>.withPackages</literal>. For example, creating a custom PostgreSQL package in an overlay can look like: </del> <ins> You can build custom PostgreSQL-with-plugins (to be used outside of NixOS) using function <literal>.withPackages</literal>. For example, creating a custom PostgreSQL package in an overlay can look like: </ins> <programlisting> self: super: { postgresql_custom = self.postgresql_11.withPackages (ps: [

Related discussion:
text: I tried to follow procedure above, but as I mentioned before, to use as suggested I needed to change the PostgreSQL user mapping in the Hydra module as specified in my comment just above this one, otherwise I would get a message. However, to read the database dump back into the new PostgreSQL installation I had to change the user mapping as follows: ... and then, after activating the configuration, I needed to run the command in the following way (as root): After doing this, the upgrade from PostgreSQL 9.4 to 9.6 seems to have completed successfully.
Related
If anyone else stumbles on this, pgupgrade seems to work now. I realized after upgrade that my db got reinitialized, so steps for me were much more brutish than that post, but in a nutshell: with new postgresql running, clear whatever got reinitialized (pgupgrade won't run if there are data around, but won't tell you what to remove... lists databases, don't know how to list users, I guessed) drop database whatever; drop user whatever; stop postgresql.service figure path for old binaries, e.g. and copy it somewhere. run the actual pgupgrade as user: restart the postgresql service if all went well after some testing pgupgrade suggests removing the old db with (disclaimer: Don't blame me if that eats your data)
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 = "1in5kvcknlpi9z1vvjw6jfmwy8k12zvbqlqfnq84qpm99r0rh00a"; }); </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:
<del> diff --git a/llm/llama.go b/llm/llama.go index f23d5d8..6563550 100644 --- a/llm/llama.go +++ b/llm/llama.go @@ -25,7 +25,6 @@ import ( "github.com/jmorganca/ollama/api" ) -//go:embed llama.cpp/*/build/*/bin/* var llamaCppEmbed embed.FS type ModelRunner struct { @@ -33,6 +32,10 @@ type ModelRunner struct { } func chooseRunners(workDir, runnerType string) []ModelRunner { +	return []ModelRunner{ +		{Path: "@llamaCppServer@"}, +	} + buildPath := path.Join("llama.cpp", runnerType, "build") var runners []string </del>

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:
pkg-config wayland xwayland <del> zig_0_12.hook </del> <ins> zig_0_13.hook </ins> ] ++ lib.optional withManpages scdoc;

Related discussion:
text: Package name: river Latest released version: 0.3.3 <!-- Search your package here: --- Current version on the unstable channel: 0.3.2 Current version on the stable/release channel: 0.3.2 <!-- 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]:
3 is only a zig 0.13 compatibility release. It’s blocked by
has been merged, this is not blocked anymore.
Code change:
, stdenv , buildPythonPackage , fetchPypi <del> , fetchpatch </del> , substituteAll , pythonOlder , geos

Related discussion:
text: Add any other context about the problem here. Please run and paste the result. repro'd on commit id
backtrace: <details<summaryBacktrace from lldb</summary</details
shapely 1.8.4 with the fix is now in pypi, I saw you wanted to upgrade it, did you get around to do it?
thanks for the reminder, committed it
Code change:
<ins> { lib, stdenvNoCC, fetchFromGitHub, glib, # These loosen security a bit, so we don't install them by default. See also: # https://github.com/hardpixel/systemd-manager?tab=readme-ov-file#without-password-prompt allowPolkitPolicy ? "none", config, systemd ? config.systemd.package, }: assert lib.elem allowPolkitPolicy [ "none" "pkexec" "systemctl" ]; stdenvNoCC.mkDerivation rec { pname = "gnome-shell-extension-systemd-manager"; version = "16"; # Upstream doesn't post new versions in extensions.gnome.org anymore, see also: # https://github.com/hardpixel/systemd-manager/issues/19 src = fetchFromGitHub { owner = "hardpixel"; repo = "systemd-manager"; rev = "v${version}"; hash = "sha256-JecSIRj582jJWdrCQYBWFRkIhosxRhD3BxSAy8/0nVw="; }; nativeBuildInputs = [ glib ]; postInstall = '' rm systemd-manager@hardpixel.eu/schemas/gschemas.compiled glib-compile-schemas systemd-manager@hardpixel.eu/schemas mkdir -p $out/share/gnome-shell/extensions mv systemd-manager@hardpixel.eu $out/share/gnome-shell/extensions '' + lib.optionalString (allowPolkitPolicy == "pkexec") '' local bn=org.freedesktop.policykit.pkexec.systemctl.policy mkdir -p $out/share/polkit-1/actions substitute systemd-policies/$bn $out/share/polkit-1/actions/$bn  --replace-fail /usr/bin/systemctl ${lib.getBin systemd}/bin/systemctl '' + lib.optionalString (allowPolkitPolicy == "systemctl") '' install -Dm0644  systemd-policies/10-service_status.rules  $out/share/polkit-1/rules.d/10-gnome-extension-systemd-manager.rules ''; passthru = { extensionUuid = "systemd-manager@hardpixel.eu"; extensionPortalSlug = "systemd-manager"; }; meta = with lib; { description = "GNOME Shell extension to manage systemd services"; homepage = "https://github.com/hardpixel/systemd-manager"; license = licenses.gpl3Only; maintainers = with maintainers; [ linsui doronbehar ]; }; } </ins>

Related discussion:
text: This needs to be done by someone and they will become the maintainer. you use this hack you will have to update the for NixOS whenever the developers of release a new update.
Upstream devs released version 16. Whoo hooo! Here is the .nix to make it work on your local machine. Again, this is not in the main nixpkgs repo. You will have to use this code and follow my "hack"above to get it to run in your local nix install. Thanks again to for the original code.
Code change:
githubId = 1891350; name = "Michael Raskin"; }; <ins> raspher = { email = "raspher@protonmail.com"; github = "raspher"; githubId = 23345803; name = "Szymon Scholz"; }; </ins> ratcornu = { email = "ratcornu@skaven.org"; github = "RatCornu";

Related discussion:
text: Project description An end-to-end encrypted, peer-to-peer file storage, sharing and communication network. It's written in Java and uses IPFS. A bit similar to Nextcloud. Metadata homepage URL: source URL: license: AGPL3 platforms: linux (JVM)
Related:
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
I marked this as stale due to inactivity. &rarr;
Still important
I marked this as stale due to inactivity. &rarr;
I've a working package of peergos. after some testing i've experienced it a little buggy, so i don't want to push it into release. Let's see what i can do as it's my first package. The example bug: after i've created task, clicking "tasks" from left menu forces me to create new task. However thecreated task is visible in my drive.
Thanks!
Code change:
<del> { lib, ocamlPackages, fetchFromGitHub, python3, dune_3, makeWrapper, poppler_utils }: </del> <ins> { lib, ocamlPackages, fetchFromGitHub, python3, dune_3, makeWrapper, poppler_utils, fzf }: </ins> ocamlPackages.buildDunePackage rec { pname = "docfd";

Related discussion:
text: needs in it's path to be able to use the fuzzy file picker, e.g. produces file picker should open <!-- 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]: