jiebi/CodeConvo huggingface dataset:
Code change:
pycharm-community = buildPycharm rec { name = "pycharm-community-${version}"; <del> version = "2019.3.4"; /* updated by script */ </del> <ins> version = "2020.1"; /* updated by script */ </ins> description = "PyCharm Community Edition"; license = stdenv.lib.licenses.asl20; src = fetchurl { url = "https://download.jetbrains.com/python/${name}.tar.gz"; <del> sha256 = "0k917si1d28fnmjyvi0fs7rkdyvi2vr0d138436lh300a6y0z6wr"; /* updated by script */ </del> <ins> sha256 = "1ld9hh9bxirsv5rwrx7wbmfaxwvxfw7cjfjqi8l0q0n93v89z90s"; /* updated by script */ </ins> }; wmClass = "jetbrains-pycharm-ce"; update-channel = "PyCharm RELEASE";

Related discussion:
text: Please update Goland to a current version. The Current Version is now 2020.1 Thx and Greetz
Code change:
''; nativeBuildInputs = [ makeWrapper unzip autoPatchelfHook ]; <del> buildInputs = [ ant jdk8 p7zip gtk3 gsettings-desktop-schemas libXxf86vm ]; </del> <ins> buildInputs = [ ant jdk p7zip gtk3 gsettings-desktop-schemas libXxf86vm ]; </ins> buildPhase = '' runHook preBuild

Related discussion:
text: Wanted to install and start sweethomed.application. the build worked without problems but when i started it, it didnt started. Steps to reproduce the behavior: sweethome3d.application via configuration file to start it Starting the Application stucks at the start screen ! Add any other context about the problem here. At the moment its installed in my user context. When i try to start it as my user over the terminal i get no errors. When i start it with "sudo sweethome3d" I get the following error, and it also dont start, also start at starting screen and vanishing from the task bar: I think these happens because its not installed as user, but propably it helps to find the issue.
Starting random applications as root seems like an unwise idea.
Apologies, I misread the error, this appears to be a separate issue
Just to confirm, which GPU do you use?
I've got the same issue, and none of the solutions given in appear to work. On my side says my GPU is . EDIT: I should mention SH3D 7.02 works fine on my setup Mmh, I just tried with , and things work just fine (even though I'm on NixOS + tells me OpenGL is happy)...
Same problem here, on NIXOS unstable. Stuck on the starting blue window. Had to install it with flatpak in the mean time... Any idea?
sorry for delay i dont get informations from messages in last time from github... really annoying... I have an Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics]
Same here, also on Intel hardware.
Based on the NixGL idea, applying the following patch works to update to the latest version and fix the driver issue on Intel. But this does not seem like the best way to go about it; I can't find a single other package messing with , and it seems more like a debugging tool than something that should be in a package.
I forgot to mention, to avoid getting terrible performance (< 1 fps), I also had to set Not sure if it's needed for others. Maybe related to my using Wayland/Sway. I also have to use to get the window displayed properly, but that's a common issue for most Java apps and tiling windowing managers.
I also ran into this issue with a Nvidia card.
Code change:
''; nativeBuildInputs = [ makeWrapper unzip autoPatchelfHook ]; <del> buildInputs = [ ant jdk8 p7zip gtk3 gsettings-desktop-schemas libXxf86vm ]; </del> <ins> buildInputs = [ ant jdk p7zip gtk3 gsettings-desktop-schemas libXxf86vm ]; </ins> buildPhase = '' runHook preBuild

Related discussion:
text: For me, was needed (with patch). I also needed . and didn't seem needed (or give noticable changes).
Code change:
<del> { stdenv, fetchurl, pkgconfig, python }: </del> <ins> { stdenv, fetchurl, pkgconfig, python, cmocka, hexdump, writeScriptBin, binutils-unwrapped }: </ins> stdenv.mkDerivation rec { pname = "unicorn-emulator"; <del> version = "1.0.1"; </del> <ins> version = "1.0.2-rc4"; </ins> src = fetchurl { url    = "https://github.com/unicorn-engine/unicorn/archive/${version}.tar.gz"; <del> sha256 = "0z01apwmvhvdldm372ww9pjfn45awkw3m90c0h4v0nj0ihmlysis"; </del> <ins> sha256 = "05w43jq3r97l3c8ggc745ai8m5l93p1b6q6cfp1zwzz6hl5kifiv"; </ins> }; <del> configurePhase = '' patchShebangs make.sh ''; buildPhase = '' ./make.sh '' + stdenv.lib.optionalString stdenv.isDarwin "macos-universal-no"; installPhase = '' env PREFIX=$out ./make.sh install ''; </del> <ins> PREFIX = placeholder "out"; MACOS_UNIVERSAL = stdenv.lib.optionalString stdenv.isDarwin "no"; NIX_CFLAGS_COMPILE = "-Wno-error"; doCheck = !stdenv.isDarwin; checkInputs = [ cmocka hexdump python.pkgs.setuptools ]; </ins> nativeBuildInputs = [ pkgconfig python ]; enableParallelBuilding = true;

Related discussion:
text: Describe the bug building the package fails. To Reproduce Steps to reproduce the behavior: and wait Expected behavior Successfully building python37Packages.pwntools to be used. Notify maintainers Maintainer: Metadata Error
Will be fixed via
lol, I didn't see this issue, I started fixing it today because I recently noticed it was broken as well :D
Code change:
</para> <section xml:id="module-services-mailman-basic-usage"> <del> <title>Basic usage</title> </del> <ins> <title>Basic usage with Postfix</title> </ins> <para> <del> For a basic configuration, the following settings are suggested: </del> <ins> For a basic configuration with Postfix as the MTA, the following settings are suggested: </ins> <programlisting>{ config, ... }: { services.postfix = { enable = true;

Related discussion:
text: Describe the bug Mailman module in NixOS requires postfix enabled and has no way to configure Mailman to work with other MTAs supported by both NixOS and mailman upstream. To Reproduce Steps to reproduce the behavior: postfix mailman the evaluation with an assertion Expected behavior The Mailman module allows to select an MTA of choice (or even adapts to the currently enabled MTA) Screenshots n/a Additional context Notify maintainers cc Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(vika): nixpkgs: Maintainer information:
It looks like exim's configuration should be RFC42-ised first if we want to inject Mailman-related settings into Exim config, which is a requirement (Mailman requires a custom Exim router and transport).
Yes, the module is currently quite opinionated. If you're willing to contribute exim support that's great.
I see how I could make it work, but the first version of it will require manual editing of Exim's config files (because RFC42-ising Exim will be a pain, even though I have some drafts on how to translate Nix into the syntax that's required), and I'm not sure if it will be merge-worthy enough :3
Exim config is complicated enough as is, I'm not sure adding an intermediate layer from nix will help that much. I also don't really see this integrating well with existing or other exim config. I'm honestly kind of surprised this works for postfix.
Code change:
let pname = "pango"; <del> version = "1.43.0"; </del> <ins> version = "1.44.6"; </ins> in stdenv.mkDerivation rec { name = "${pname}-${version}"; src = fetchurl { url = "mirror://gnome/sources/${pname}/${stdenv.lib.versions.majorMinor version}/${name}.tar.xz"; <del> sha256 = "1lnxldmv1a12dq5h0dlq5jyzl4w75k76dp8cn360x2ijlm9w5h6j"; </del> <ins> sha256 = "0v7qq3fv1c0dl80d4qxsvd6cmhh4ngih3w0zc40f4dw7hfx427iy"; </ins> }; <ins> # 1.44.6-2 is not available from the usual mirrors yet, # so applying from gitlab patches = [ (fetchpatch { url = "https://gitlab.gnome.org/GNOME/pango/commit/8a408d4f25ddb0e3d6020cdde0cd8f8a19ee8db2.patch"; sha256 = "0l0hxwbijqrfvka302ijgih9jafc2ffs3d6d4v7bwynpn54lmza7"; }) ]; </ins> # FIXME: docs fail on darwin outputs = [ "bin" "dev" "out" ] ++ optional (!stdenv.isDarwin) "devdoc";

Related discussion:
text: , (nixos-19.09) Scanned versions: nixos-19.09: . May contain false positives.
This is now fixed for 1.43 on master and 19.09:
Thanks :heart:
Code change:
<ins> { lib, buildPythonPackage, fetchPypi, orjson}: buildPythonPackage rec { pname = "fvs"; version = "0.3.4"; src = fetchPypi { inherit version; pname = "FVS"; extension = "tar.gz"; sha256 = "sha256-yYd0HzdwbqB9kexJjBRRYmdsoWtZtcjCNRz0ZJVM5CI="; }; propagatedBuildInputs = [ orjson ]; # no tests in src doCheck = false; pythonImportsCheck = [ "fvs" ]; meta = with lib; { description = "File Versioning System with hash comparison and data storage to create unlinked states that can be deleted"; homepage = "https://github.com/mirkobrombin/FVS"; license = licenses.mit; maintainers = with maintainers; [ bryanasdev000 ]; }; } </ins>

Related discussion:
text: Vulkan/dxvk doesnt work on bottles. Vulkan is working correctly on my laptop as vkcube, vulkaninfo and the game im trying to run on bottles (that i ran thru wineWowPackages.staging + dxvk install from the official archive file) run perfectly. Steps to reproduce the behavior: bottles a bottle for gaming a game. the "directx error" pop up. Also, the dxvk log files say that the "VKKHRsurface" extension failed to load. DXVK/Vulkan should work on bottles. ! Please run and paste the result.
Having the exact same Issue on 22.11pre393800. (Raccoon)
If fails then there is a driver issue. Vulkan wont be able to draw anything to screen without it. When it occurs in proton issues it's usually a missing 32bit Vulkan library. Tho there can ofc probably be other causes
update: using the system wine doesn't fix dxvk either. only running thru the command line does. As i said, running it thru wine on the terminal does work, so something in the bottles thing is not working right.
I found the cause: these hardcoded paths right there: With this extra lines in , Vulkan will work on Bottles: I'm not sure if this is the best way to solve it, though. Tested only on a 64-bit bottle (I don't know if 32-bit bottles need to also link ). .
!!! nice find!
Code change:
<ins> { lib, buildPythonPackage, fetchPypi, orjson}: buildPythonPackage rec { pname = "fvs"; version = "0.3.4"; src = fetchPypi { inherit version; pname = "FVS"; extension = "tar.gz"; sha256 = "sha256-yYd0HzdwbqB9kexJjBRRYmdsoWtZtcjCNRz0ZJVM5CI="; }; propagatedBuildInputs = [ orjson ]; # no tests in src doCheck = false; pythonImportsCheck = [ "fvs" ]; meta = with lib; { description = "File Versioning System with hash comparison and data storage to create unlinked states that can be deleted"; homepage = "https://github.com/mirkobrombin/FVS"; license = licenses.mit; maintainers = with maintainers; [ bryanasdev000 ]; }; } </ins>

Related discussion:
text: <!-- 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 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: bottles <!-- The current version can be found easily with the same process as 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: 2022.5.28-trento-3 desired version: 2022.7.14-brescia-1 <!-- 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.
While automatic update using was removed by in you need to wait while we will "get auto updates from r-rynatm"
That not true. I removed the over complicated updater in which wasn't necessary at all. Since r-ryantm also uses nix-update there was also no need to replace it. That's wrong. You can always create an update PR yourself by running ` or by manually update the package and create a PR with that. r-ryantm goes through all packages so it can sometimes take a few days until the update PR is created. Also nix-update is very lightweight with minimal dependencies, so there is not really a reason to not use it. It also does not require any kind of token or authentication.
Bottles the version released after the one currently present in nixpkgs, was released on June 13. Over one month has passed, so something about the auto-updater isn't working.
The latest r-ryantm log is here . Not sure why that is not working like it should.
I guess a update script is needed for this case :disappointed: Since the package is using , it HAS a fallback update script , so nixpkgs-update is no longer trying to figure out the latest version itself but just run the script.
Code change:
<ins> { lib, buildPythonPackage, fetchPypi, orjson}: buildPythonPackage rec { pname = "fvs"; version = "0.3.4"; src = fetchPypi { inherit version; pname = "FVS"; extension = "tar.gz"; sha256 = "sha256-yYd0HzdwbqB9kexJjBRRYmdsoWtZtcjCNRz0ZJVM5CI="; }; propagatedBuildInputs = [ orjson ]; # no tests in src doCheck = false; pythonImportsCheck = [ "fvs" ]; meta = with lib; { description = "File Versioning System with hash comparison and data storage to create unlinked states that can be deleted"; homepage = "https://github.com/mirkobrombin/FVS"; license = licenses.mit; maintainers = with maintainers; [ bryanasdev000 ]; }; } </ins>

Related discussion:
text: However seems like cannot handle the version , so it will fail at You may just try Repology gets software latest version from various Linux distributions that ships this app, so since AUR and OpenMandriva have 2022.6.14 (no suffix) the latest version is 2022.6.14. Looks like there is also an related report in Note that nixpkgs-update does not really tries to bump package in this way because it has an fallback update script.
Code change:
}; webapps = mkOption { <del> type = types.listOf types.package; </del> <ins> type = types.listOf types.path; </ins> default = [ tomcat.webapps ]; defaultText = "[ pkgs.tomcat85.webapps ]"; description = "List containing WAR files or directories with WAR files which are web applications to be deployed on Tomcat";

Related discussion:
text: The option is declared as "list of packages". To me, it seems too restrictive, since it prevents useful configurations where web applications are copied from some mutable location in the filesystem, like this: . (Note that for tomcat's virtualHosts, the similar configurations are accepted and work fine just fine! I'm going to use them on my server.) Moreover, the current type was possibly chosen without much thought: it was a part of the long commit which mass- type specifications. My proposal is to change the type of from to . Right now, this kind of configuration produces an error: system: host os: multi-user?: sandbox: version: channels(paul): channels(root): nixpkgs:
Code change:
weechat = assert lib.all (p: p.enabled -> ! (builtins.elem null p.buildInputs)) plugins; stdenv.mkDerivation rec { <del> version = "2.2"; </del> <ins> version = "2.3"; </ins> name = "weechat-${version}"; src = fetchurl { <del> url = "http://weechat.org/files/src/weechat-${version}.tar.bz2"; sha256 = "0p4nhh7f7w4q77g7jm9i6fynndqlgjkc9dk5g1xb4gf9imiisqlg"; </del> <ins> url = "https://weechat.org/files/src/weechat-${version}.tar.bz2"; sha256 = "0mi4pfnyny0vqc35r0scn6yy21y790a5iwq8ms7kch7b7z11jn9w"; </ins> }; outputs = [ "out" "man" ] ++ map (p: p.name) enabledPlugins;

Related discussion:
text: 3 is out! I'm not sure what's changed but it's at least 200% more better, and has a plugin for making you toast :stuckouttongue: . The release notes are here: and are as follows: Anyway I imagine someone'll be excited about the new version :grin: so thought I'd share.
Haha, a proper changelog is here: my bad :innocent:.
Code change:
<link linkend="opt-services.touchegg.enable">services.touchegg</link>. </para> </listitem> <ins> <listitem> <para> <link xlink:href="https://github.com/pantheon-tweaks/pantheon-tweaks">pantheon-tweaks</link>, an unofficial system settings panel for Pantheon. Available as <link linkend="opt-programs.pantheon-tweaks.enable">programs.pantheon-tweaks</link>. </para> </listitem> </ins> </itemizedlist> </section> <section xml:id="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:
<link linkend="opt-services.touchegg.enable">services.touchegg</link>. </para> </listitem> <ins> <listitem> <para> <link xlink:href="https://github.com/pantheon-tweaks/pantheon-tweaks">pantheon-tweaks</link>, an unofficial system settings panel for Pantheon. Available as <link linkend="opt-programs.pantheon-tweaks.enable">programs.pantheon-tweaks</link>. </para> </listitem> </ins> </itemizedlist> </section> <section xml:id="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:
type = types.listOf (types.submodule { options = { name = mkOption { <del> type = types.listOf types.str; </del> <ins> type = types.str; </ins> description = "name of the virtualhost"; <ins> }; webapps = mkOption { type = types.listOf types.path; description = '' List containing web application WAR files and/or directories containing web applications and configuration files for the virtual host. ''; </ins> default = []; }; };

Related discussion:
text: Commit introduced type specification for (which was absent before), but this specification is wrong. From within release-18.03, import the tomcat module from the master branch, and create a minimal Tomcat configuration that uses : And see it fails: When using the native module from release-18.03, everything works. system: host os: multi-user?: sandbox: version: channels(paul): channels(root): nixpkgs:
It's only semi-related, but why on earth is the type of a list of packages, and not just a list of paths or strings?? It severely limits the configuration options for no apparent gain.
For the record, was an issue about overly restrictive type of .
Code change:
}, "libpng": { "url": "https://skia.googlesource.com/third_party/libpng.git", <del> "rev": "386707c6d19b974ca2e3db7f5c61873813c6fe44", "sha256": "sha256-67kf5MBsnBBi0bOfX/RKL52xpaCWm/ampltAI+EeQ+c=" </del> <ins> "rev": "144b348e072a78e8130ed0acc452c9f039a67bf2", "sha256": "sha256-eTF7q7hR4S1OqV2oPQKmcHujA5Od4rGMc5879kT0SkE=" </ins> } }

Related discussion:
text: Package name: neovide Latest released version: 0.13.0 <!-- Search your package here: --- Current version on the unstable channel: 0.12.2 Current version on the stable/release channel: 0.11.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. As an additional note, I am currently working on updating Neovide myself. Part of my plans this summer are to begin giving at least two contributions to Nix/NixOS/Nixpkgs each week. I intend to begin maintaining Neovide as part of this goal. Gotta figure out how to A.) apply as a maintainer and B.) figure out if I'm even eligible. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
For future issues/prs/etc. where should I add an additional summary/context if I have any? I've sandwiched it between the Note for maintainers... and Add a reaction... sections in this issue.
Code change:
# source code of the previous release to a different directory urls = [ "http://www.iram.fr/~gildas/dist/gildas-src-${srcVersion}.tar.xz" "http://www.iram.fr/~gildas/dist/archive/gildas/gildas-src-${srcVersion}.tar.xz" ]; <del> sha256 = "sha256-Eq6S5S8xrhkCo6O2wUaHnoMDVG9WeiSurGvOc+2JKbM="; </del> <ins> sha256 = "sha256-dZ03J3I1dgoSgSc9yGfO13ZvNawCSYKN3+SGvp1eyGA="; </ins> }; nativeBuildInputs = [ pkg-config groff perl getopt gfortran which ];

Related discussion:
text: Steps to reproduce the behavior: Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: