jiebi/CodeConvo huggingface dataset:
Code change:
sourceProvenance = with sourceTypes; [ binaryBytecode ]; license = licenses.unfree; platforms = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" ]; <del> maintainers = with maintainers; [ flokli ]; </del> <ins> maintainers = with maintainers; [ flokli dylanmtaylor ]; </ins> hydraPlatforms = [ ]; }; }

Related discussion:
text: Package name: oracle-instantclient Latest released version:21.9.0.0.0 <!-- Search your package here: --- Current version on the unstable channel:19.16.0.0.0 Current version on the stable/release channel:19.16.0.0.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! -- looks like it tried to upgrade v19 of instant client, but it is stale and not targeting v21. 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.
It looks like you were the last one to touch instant client.
Package sources:
Code change:
- [touchegg](https://github.com/JoseExposito/touchegg), a multi-touch gesture recognizer. Available as [services.touchegg](#opt-services.touchegg.enable). <ins> - [pantheon-tweaks](https://github.com/pantheon-tweaks/pantheon-tweaks), an unofficial system settings panel for Pantheon. Available as [programs.pantheon-tweaks](#opt-programs.pantheon-tweaks.enable). </ins> ## Backward Incompatibilities {#sec-release-21.11-incompatibilities}

Related discussion:
text: Project description Pantheon Tweaks is a Switchboard plug allowing users to somewhat tweak Pantheon (elementary OS's DE) settings of the more hidden kind, not normally available from Switchboard. As NixOS has Pantheon packaged, it might be of use in Nixpkgs. Metadata homepage URL: source URL: license: platforms: same as Pantheon Depending on Pantheon version currently in Nixpkgs, the predecessor elementary-tweaks, also GPLv3, might be of more use:
As I maintain Pantheon in NixOS, I approve of this being packaged in the future, but not , because it's archived and IIRC I denied that .
Then we should probably do it once Pantheon in NixOS advances to whatever version elementary OS 6 Odin will have - this'll probably happen once elementary OS 6 will get released.
Ah yes, the repo says "Pantheon Tweaks is currently only supported on elementary OS Odin" :+1:
Did some initial work for this (), would you like to try that? Will need Pantheon 6 () and following line in your NixOS configuration file: Update: I will move this out from the pantheon namespace when creating the PR due to reasons below.
Did some initial work for this great! would you like to try that? of course works great. only the force darkmode did not work in minder program. haven't tested more... ! ! maybe it could be enabled by an option like ? So it's consistent with other options like .
Tested 1.13.1 on both elementary OS (installed via appcenter) and NixOS (btw minder in Nixpkgs seems out-of-date, just opened a PR: ), I guess this should be an issue to minder, as minder is trying to read information from of granite (, ), so it should respect settings from switchboard-plug-pantheon-shell, while what pantheon-tweaks does is (I guess) setting under you gtk config file and I am not sure how handle this. You can check this with: ! I am not sure as this is not an official part of Pantheon. I guess it should be okay to do this.
I am not sure as this is not an official part of Pantheon.
Code change:
- [touchegg](https://github.com/JoseExposito/touchegg), a multi-touch gesture recognizer. Available as [services.touchegg](#opt-services.touchegg.enable). <ins> - [pantheon-tweaks](https://github.com/pantheon-tweaks/pantheon-tweaks), an unofficial system settings panel for Pantheon. Available as [programs.pantheon-tweaks](#opt-programs.pantheon-tweaks.enable). </ins> ## Backward Incompatibilities {#sec-release-21.11-incompatibilities}

Related discussion:
text: yes, that is a concern, but we can make that clear in the description do you think it is acceptable to enable a third-party component (e.g. pantheon-tweaks) with an option like if we clarify that it is third-party in the description, which is for example displayed at the or in the documentation?
I would not recommend packaging this tweaks app. It regularly breaks since it references gsettings that aren't considered API. That's just my personal opinion though I'm not familiar with NixOS options or what that means so I can't really offer an opinion there
thanks for your opinion! the program exists and people want to use it and we at nixos want to empower users to do what they want, even if the choices could be considered bad, like installing proprietary software. that's why it's considered for advanced users. you are responsible for the choices you make and you can end up with a broken system, but it's easy to roll back to a working state. experimenting is encouraged So i think it's fine for us to offer the package, but we can clarify that "it's not recommended by elementary because it regularly breaks". I'm not familiar with NixOS options or what that means so I can't really offer an opinion there i try to explain quickly: on nixos the whole system is configured by one (or multiple) config. file. as a consequence is read-only if you want to use pantheon, you add this line to the config: that sets up pantheon with default settings. there are options to change those default, like to remove default apps you don't need... so the question here is, all current options with in the name relate to official pantheon software, but would relate to third party software, which is not visible from the name. so it might not be 100% clear all the time so my suggestion is to clarify it at least in the description of the option that it is third-party and not recommended the concern is that it could devaluate you branding like the name "pantheon"
ah okay yeah. If possible then it would great if that was not namespaced with actual parts of pantheon and instead namespaced the way you would hand extensions or apps if there's no special convention for extensions. Thanks!
i suggest then
Code change:
patchShebangs --build configure ''; <ins> # JDK's build system attempts to specifically detect # and special-case WSL, and we don't want it to do that, # so pass the correct platform names explicitly configurePlatforms = ["build" "host"]; </ins> configureFlags = [ "--with-boot-jdk=${openjdk-bootstrap.home}" "--with-version-pre="

Related discussion:
text: They're trying to be smart: We should probably patch that check out, but maybe people with actual Java experience will have better ideas.
We need to patch that. Neither do we want to provide cygpath nor can we wslpath because that would most likely try to escape the sandbox.
The thing here is that they see WSL and automatically assume we're cross-compiling to a Windows target, which we're not. We can patch this out, or maybe we can force it to not cross-compile somehow, or maybe we can make lie.
I would recommend to just patch that out.
Code change:
patchShebangs --build configure ''; <ins> # JDK's build system attempts to specifically detect # and special-case WSL, and we don't want it to do that, # so pass the correct platform names explicitly configurePlatforms = ["build" "host"]; </ins> configureFlags = [ "--with-boot-jdk=${openjdk-bootstrap.home}" "--with-version-pre="

Related discussion:
text: I'm trying to use it on aarch64 and this is failing: [6/257] Building CXX object FAILED: /nix/store/fsn9mccnjinl212ypa3rx8b8647s9klh-gcc-wrapper-12.2.0/bin/g++ -DCEFUSESANDBOX -DNDEBUG -DWRAPPINGCEFSHARED -DFILEOFFSETBITS=64 -DSTDCCONSTANTMACROS -DSTDCFORMATMACROS -I/build/source/thirdparty/cef/cefbinary104.4.26+g4180781+chromium-104.0.5112.102linux64minimal -O3 -DNDEBUG -fno-strict-aliasing -fPIC -fstack-protector -funwind-tables -fvisibility=hidden --param=ssp-buffer-size=4 -pipe -pthread -Wall -Werror -Wno-missing-field-initializers -Wno-unused-parameter -Wno-error=comment -Wno-comment -Wno-deprecated-declarations -m64 -march=x86-64 -fno-exceptions -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -std=c++14 -Wsign-compare -Wno-undefined-var-template -Wno-literal-suffix -Wno-narrowing -Wno-attributes -O2 -fdata-sections -ffunction-sections -fno-ident -UFORTIFYSOURCE -DFORTIFYSOURCE=2 -MD -MT -MF -o -c /build/source/thirdparty/cef/cefbinary104.4.26+g4180781+chromium- g++: error: unrecognized command-line option '-m64' ninja: build stopped: subcommand failed. error: builder for '/nix/store/a7r53z6050vvhlmwnxac6c6kp41gcz2g-jcef-jetbrains-' failed with exit code 1; last 10 log lines: For full logs, run 'nix log /nix/store/a7r53z6050vvhlmwnxac6c6kp41gcz2g-jcef-jetbrains-'.
Code change:
patchShebangs --build configure ''; <ins> # JDK's build system attempts to specifically detect # and special-case WSL, and we don't want it to do that, # so pass the correct platform names explicitly configurePlatforms = ["build" "host"]; </ins> configureFlags = [ "--with-boot-jdk=${openjdk-bootstrap.home}" "--with-version-pre="

Related discussion:
text: error: 1 dependencies of derivation '/nix/store/9mds0h6675lnh8hgam63xycvv8lrb01v-jetbrains-jdk-jcef-17.0.6-' failed to build
WSL2 on aarch64? Also, this error is for Chromium.
Sorry, never mind. I'm having an issue with , that has a dependency on CEF. I posted in an incorrect place. I opened a separate ticket. Please ignore.
Code change:
, config , stdenv , fetchFromGitHub <ins> , fetchurl </ins> , cmake , qt6 , fmt

Related discussion:
text: Package name: gpt4all Latest released version: 3.2.1 <!-- Search your package here: --- Current version on the unstable channel: 2.8.0 Current version on the stable/release channel: 2.7.5 <!-- 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]:
Hi, I don't maintain GPT4All any longer, I switched to some other technologies (Open-WebUI).
haha, maybe i'll give that one a try then :) ty for all your hard work
Code change:
<del> { lib , stdenv , fetchFromGitHub , cmake }: stdenv.mkDerivation rec { pname = "iir1"; version = "1.9.4"; src = fetchFromGitHub { owner = "berndporr"; repo = "iir1"; rev = version; hash = "sha256-T8gl51IkZIGq+6D5ge4Kb3wm5aw7Rhphmnf6TTGwHbs="; }; nativeBuildInputs = [ cmake ]; meta = { description = "A DSP IIR realtime filter library written in C++"; downloadPage = "https://github.com/berndporr/iir1"; homepage = "http://berndporr.github.io/iir1/"; license = lib.licenses.mit; maintainers = [ lib.maintainers.AndersonTorres ]; platforms = lib.platforms.unix; }; } </del>

Related discussion:
text: Steps to reproduce the behavior: dosbox-staging on darwin Complaining that alsa-lib not available on darwin I suggest referencing the derivation of in which use to opt-in dependencies P.S. wonder why the maintenance of this package is separated from and Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I don't have a Darwin machine. Nice. A full log would be nicer of course, but nice nonetheless. Wonder why they should be maintained by the same people.
Code change:
, enableDC1394    ? false, libdc1394 , enableDocs      ? false, doxygen, graphviz-nox <del> , AVFoundation, Cocoa, VideoDecodeAcceleration, bzip2 </del> <ins> , AVFoundation, Cocoa, VideoDecodeAcceleration, CoreMedia, MediaToolbox, bzip2 </ins> }: assert blas.implementation == "openblas" && lapack.implementation == "openblas";

Related discussion:
text: Describe the issue In the opencv build for mac, why is off by default? What needs to be done to enable it? (either development work, dependencies that aren't yet nixpkgs, or, if possible, how to manually override the argument and simply set to ) To Reproduce See above Expected behavior There may be a good reason it's disabled, so I can't say that I'd expect videoio to be enabled by default. Notify maintainers Metadata Please run and paste the result. Maintainer information:
It was removed here 15 months ago: See this PR: due to apple removing most of QTkit in 10.12 Brew does not use this option. You can use an overlay or a nixpkgs checkout with this patch to build with videoio The following will drop you into a nix-shell with the patched opencv, which you can use for testing. I'm not sure if it builds. FWIW, I get the following build failure which indicates the upstream issue might not be resolved, or we're missing some thing in our derivation.
I was originally attempting to use an overlay. After getting nowhere, I made a , which is what redirected me to the nix build. So if you want to help me close that thread, that'd be awesome cause both me and the person that helped me still don't know how to access/change the from an overlay.
Code change:
fetchFromGitHub, immich, python3, <ins> nixosTests, </ins> }: let python = python3.override {

Related discussion:
text: Build on () and when running I find the following in the runtime closure: pytest shouldn't be a runtime dependency Seems to be a regression, did not have this issue Might be able to bisect this one, but it'll take a while <!-- 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]:
After bisecting, first bad commit is (
Code change:
runHook postUnpack ''; <ins> # Prevent double wrapping dontWrapGApps = true; </ins> installPhase = '' runHook preInstall

Related discussion:
text: Describe the bug When adding a local directory to spotify client, it always fails due to missing gtk schema(s) To Reproduce Steps to reproduce the behavior: on button Expected behavior Open a file chooser to select which directory to be . Screenshots If applicable, add screenshots to help explain your problem. Additional context Running spotify with flag from console gives me 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 Maintainer information:
I think that this issue is not NixOS specific:
Still seems to be an issue. I'm using flakes so above is not applicable I'm on.
Tail end of strace.
Yep I can confirm that. However, as IvanMalison commented above, the bug might be not by nixos but by upstream.
I'm getting the same issue as OP when clicking the button I also tried this on EndeavourOS with the same version of spotify and there it works flawlessly. So I think this is actually a nixpkgs problem and not something upstream related. Maybe the issue can be reopened?
Code change:
assert lib.assertMsg (!hidpiXWayland) "The option `hidpiXWayland` has been removed. Please refer https://wiki.hyprland.org/Configuring/XWayland"; stdenv.mkDerivation (finalAttrs: { pname = "hyprland" + lib.optionalString debug "-debug"; <del> version = "0.35.0"; </del> <ins> version = "0.36.0"; </ins> src = fetchFromGitHub { owner = "hyprwm"; repo = finalAttrs.pname; rev = "v${finalAttrs.version}"; <del> hash = "sha256-dU5m6Cd4+WQZal2ICDVf1kww/dNzo1YUWRxWeCctEig="; </del> <ins> hash = "sha256-oZe4k6jtO/0govmERGcbeyvE9EfTvXY5bnyIs6AsL9U="; </ins> }; patches = [

Related discussion:
text: Package name: hyprland Latest released version: 0.36.0 <!-- Search your package here: --- Current version on the unstable channel: 0.35.0 Current version on the stable/release channel: 0.32.3 <!-- 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]: The 035.0 has a bug that makes my system crash very often (nullptr when monitor is disconnected) the issue is supposed to be fixed in 0.36.0.
Code change:
<ins> { lib, buildPythonPackage, fetchPypi, pyscard, ecdsa, pyaes , pythonOlder }: buildPythonPackage rec { pname = "pysatochip"; version = "0.11.4"; disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; sha256 = "sha256-Jj/zZIS9aXmZ2xdi29Eun7iRIrIk9oBlrtN9+6opIMo="; }; propagatedBuildInputs = [ pyscard ecdsa pyaes ]; pythonImportsCheck = [ "pysatochip" ]; meta = with lib; { description = "Simple python library to communicate with a Satochip hardware wallet"; homepage = "https://github.com/Toporin/pysatochip"; license = licenses.lgpl3Only; maintainers = with maintainers; [ oxalica ]; }; } </ins>

Related discussion:
text: Describe the bug failed to build on master. To Reproduce Steps to reproduce the behavior: nixpkgs master Expected behavior It builds. 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. system: host os: multi-user?: sandbox: version: channels(root): channels(oxa): nixpkgs: Maintainer information:
Code change:
{ mkDerivation , lib , fetchFromGitHub <ins> , substituteAll </ins> , qtbase , qtwebengine , qtdeclarative

Related discussion:
text: The tray icon appears, but he according window shows: Steps to reproduce the behavior: syncthingtray (through home.packages in home-manager in my case) on the tray icon The proper GUI with shiny buttons and stuff
Didn't have time to do actual digging yet, but seems like it's actually a matter of launching it / nixos weirdness rather then the package itself at fault: if I run manually from the terminal it actually works as expected. if I have it launched by plasma's autostart it sits in the tray failed with the message above. if I have it launched as user systemd service through the according home-manager option, it fails to launch because it can not find the tray altogether (probably launched before plasma is ready). So the question is, why is it different when launched from autostart... The message shows the right path in after all... (Disclaimer: total nixos noob here. Maybe it's obvious for a more experienced user...)
I'd investigate this by comparing the environment of your terminal to the environment of autostart's file - try to override the line to something like:
Oh I see what's the problem.. the file generates is pointing in to the unwrapped executable.. This needs to be patched locally in nixpkgs!
That would explain it. What do you mean by "patched locally"?
I mean this:
you are invited to test the fix for your issue in .
I'm really sorry it took me forever to actually test it - had issues with the system I use it on. Anyway, the desktop file wasn't my issue either - I didn't realize the thing in tray is not the autostarted desktop file / syncthingtray process, but the plasmoid which is apparently a completely different beast running within the plasmashell process rather then a separate one. It appears automatically in tray unless I use syncthingtray with and can not be removed from there through plasma controls. Launching the process actually creates a second icon, which behaves properly.
I'm not sure I followed.. Does it work if you set ? has landed in so the environment issue fixed there should affect you somehow I think. Feel free to reopen the issue.
No, the plasmoid is what fails. The plasmoid seems to be launched in a different way, independent from the desktop file.
Code change:
{ mkDerivation , lib , fetchFromGitHub <ins> , substituteAll </ins> , qtbase , qtwebengine , qtdeclarative

Related discussion:
text: Whenever I include syncthingtray in the home manager with (which is default), the plasmoid appears in tray on next login - but no process exists. It seems to run as part of plasmashell instead and is not in the autostart at this point. Autostart seems to be a different way to start it as an alternative to the plasmoid stuff, the plasmoid is however what is running by default with the current syncthingtray package. Doesn't seem like I have permissions to reopen it in place.
According to the initially reported issue description it is indeed the Plasmoid that's causing problems here. On Plasma the Plasmoid is supposedly the preferred UI. So the goal should be to fix it. If you nevertheless want to use the executable instead you can do that of course as well. Then you can simply disable the Plasmoid by removing it from all panels/screen as usual. If the Plasmoid is shown as part of Plasma's system tray Plasmoid, you can disable it via the settings of the system tray Plasmoid. To fix the actual issue of the Plasmoid: Supposedly a file is missing in the package. The full list of files to be contained by the package should currently look like this: Of course the exact paths depend on your install prefix and paths of your Qt and Plasma installation. Maybe something is not missing but installed to the wrong directory. Did the Plasmoid (not the stand-alone executable) ever work with your packaging? If it did then I'd try to compare the last working package with the first bad.
Note that an override for the executable path (via a CMake option that then sets a define which is used if present like in your patch) could be upstreamed.
I was thinking about it just today, since usually you'd want it to be the permanent symlink and not the path (to the wrapped executable) that might be removed after a garbage collection.. Let's continue this discussion in
What is the status on this?
Code change:
{ mkDerivation , lib , fetchFromGitHub <ins> , substituteAll </ins> , qtbase , qtwebengine , qtdeclarative

Related discussion:
text: I'm still encountering this issue on my machine
I'm not sure what more could I do here.. I will report here after comment that there are no much differences between the files installed by our package and what should be installed: <details<summary<codediff our- upstream-</code</summary</details
Is this a problem affecting all NixOS users or is it just reproducible in the setup of a few people. For debugging it might help to start with the env variable set.
I'd only compare the packaging with how other Plasmoids for NixOS are packaged. Maybe there actually needs to be a difference compared to my "upstream packaging".
I don't experience this issue, here on Gnome, naturally. Other packages in Nixpkgs, like , and also put files in , according to .
Yes, you would obviously need to start a Plasma session to reproduce the issue. (Or just launch or in another session. I suppose will work in any X11 session and in any X11 or Wayland session.) Maybe it makes more sense if the users that actually use Plasma would do further debugging on their side, though. By the way, how do you use Syncthing Tray under GNOME? Last time I've checked whether it works there was no general support for system tray icons at all and issues like suggest that GNOME has no generic system tray icon support at all right now. If there are any workarounds those might be worth documenting under and could be extended with a remark to the workaround section.
As a note, I'm a pretty new NixOS user, but I switched yesterday to the unstable channel, and syncthingtray is working completely fine now.
Using .
Thanks for the report. I wonder what was the problem... I'll close this in the meantime, unless someone from the stable channels will give a detailed bug report.