jiebi/CodeConvo huggingface dataset:
Change:
<ins> { lib, python3Packages, fetchPypi, pytestCheckHook, pythonRelaxDepsHook, pythonOlder, poetry-core, colorama, tabulate, unidecode, }: python3Packages.buildPythonPackage rec { pname = "cli-ui"; version = "0.17.2"; pyproject = true; disabled = pythonOlder "3.8.1"; src = fetchPypi { inherit pname version; hash = "sha256-L2flDPR052rRYMPmYLutmL+LjfuNhHdl86Jht+E8Bfo="; }; pythonRelaxDeps = [ "tabulate" ]; nativeBuildInputs = [ pythonRelaxDepsHook ]; build-system = [ poetry-core ]; dependencies = [ colorama tabulate unidecode ]; nativeCheckInputs = [ pytestCheckHook ]; pythonImportsCheck = [ "cli_ui" ]; meta = with lib; { description = "Build Nice User Interfaces In The Terminal"; homepage = "https://github.com/your-tools/python-cli-ui"; license = licenses.bsd3; maintainers = with maintainers; [ slashformotion ]; }; } </ins>

Discussion:
Project description Tbump helps you bump the version of your project easily. It is a simple cli. Metadata homepage URL: source URL: license: BSD 3-Clause platforms: Anything that run python Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
''; fishPreInitHooks = '' <del> # source nixos environment if we're a login shell </del> <ins> # source nixos environment # note that this is required: #   1. For all shells, not just login shells (mosh needs this as do some other command-line utilities) #   2. Before the shell is initialized, so that config snippets can find the commands they use on the PATH </ins> builtin status --is-login <ins> or test -z "$__fish_nixos_env_preinit_sourced" -a -z "$ETC_PROFILE_SOURCED" -a -z "$ETC_ZSHENV_SOURCED" </ins> and test -f /etc/fish/nixos-env-preinit.fish and source /etc/fish/nixos-env-preinit.fish <ins> and set -gx __fish_nixos_env_preinit_sourced 1 </ins> test -n "$NIX_PROFILES" and begin

Discussion:
Fish usually has available, but the aliases are now missing, when the shell is not a login shell (presumably because of ). Have Then launch as a not-login shell. Try to use . System: 17.09pre107265. (Hummingbird)
Agh, what a mess. Thanks for raising this issue.
I think this issue is a little subtler than one would think: aliases are sourced, but only when the parent shell has not already sourced the interactive configuration. This is out of line with the behavior of the other shells on NixOS. I have a fix which I've tested with your example here. I will post a link to the relevant PR momentarily (after I put it up).
So apparently outgoing SSH is blocked from the WiFi on this cruise ship, so I can't push commits with the remotes I have set up, and my sister is nagging me to get off the computer so we can go out. If you need a quick fix on your own machine (I will be back later today, while I still have internet access, to submit the new PR), just change the lines in the NixOS module for fish () to and your aliases will get sourced every time the shell starts, so changes will be reflected without a reboot or manually unsetting the relevant variable before starting a new shell (). (The latter will do the trick if you want a quick fix without any changes to your Nixpkgs tree.)
there's a fix in this commit:
Thanks!

It looks like PR messed something up with fish environment as now connecting to a server with mosh fails giving fish: Unknown command 'mosh-server new -c 256 -s -l LANG=enUS.UTF-8 -l LCALL=enUS.UTF-8' fish: mosh-server 'new' '-c' '256' '-s' '-l' 'LANG=enUS.UTF-8' '-l' 'LCALL=enUS.UTF-8' I reverted the commit (it was mistakenly merged into 17.03) and mosh started working again. the system
I will likely not get a chance to really look into this until next week, but I will definitely figure out what went wrong here. Sorry about this! :-(
Don't worry too much, it's not something critical (hopefully it's the only thing affected). I'll try to sort this out though I have little experience here.
there's a fix in this commit:
Change:
xenPackages = recurseIntoAttrs (callPackage ../applications/virtualization/xen/packages.nix {}); <del> xen = xenPackages.xen_4_5-vanilla; xen-slim = xenPackages.xen_4_5-slim; xen-light = xenPackages.xen_4_5-light; </del> <ins> xen = xenPackages.xen-vanilla; xen-slim = xenPackages.xen-slim; xen-light = xenPackages.xen-light; </ins> xen_4_8 = xenPackages.xen_4_8-vanilla; xen_4_8-slim = xenPackages.xen_4_8-slim; xen_4_8-light = xenPackages.xen_4_8-light;

Discussion:
Security support for Xen 4.5 (our current default version) ended January 2018, so we should change the default to 4.8 in 18.03 (and remove 4.5 in the future).
what's your opinion on this?
See .
Change:
pygobject3 ]; <del> dontWrapGapps = true; pythonPath = with python3Packages; requiredPythonModules [ dbus-python xlib pygobject3 ]; </del> postInstall = '' <del> rm $out/bin/autokey-qt buildPythonPath "$out $pythonPath" makeWrapperArgs+=( "''${gappsWrapperArgs[@]}" # for autokey-shell ModuleNotFoundError: No module named 'autokey' --prefix "PYTHONPATH" ":" "$out/lib/${python3Packages.python.libPrefix}/site-packages" --prefix "PYTHONPATH" ":" "$program_PYTHONPATH" ) </del> <ins> # remove Qt version which we currently do not support rm $out/bin/autokey-qt $out/share/applications/autokey-qt.desktop </ins> ''; meta = {

Discussion:
When running autokey it does not work (it errors). Steps to reproduce the behavior: the package from nixpkgs. in the terminal. The program should work. This is the error message: After searching through the autokey repo, I believe the X protocol errors can be safely ignored. The important part is the final error (about GSettings schemas). Autokey was last updated 2 years ago, it's quite out of date. I haven't tested if the latest version fixes this problem or not. Also, it seems that the program is missing, only / / are installed. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (doesn't seem to exist anymore) Maintainer information:
Autokey qt was hard to get working so I chose to delete it during the build the gtk should work since This pr and I also updated autokey in it
Strange, I am using version 0.95.10, but I still get the error. What desktop environment are you using?
Sway, I'll try in a fresh kde vm later
I marked this as stale due to inactivity. &rarr;
Change:
] }, "onlyoffice": { <del> "sha256": "10axh9a4w8y3iw95xdjn4q8wjg5459dki42xb6cax5ikimyfv07j", "url": "https://github.com/ONLYOFFICE/onlyoffice-nextcloud/releases/download/v7.8.0/onlyoffice.tar.gz", "version": "7.8.0", </del> <ins> "sha256": "12hzmngps86ha4lcfwaf62svfz41aywykq0z419r644g5i4v7raq", "url": "https://github.com/ONLYOFFICE/onlyoffice-nextcloud/releases/download/v7.9.0/onlyoffice.tar.gz", "version": "7.9.0", </ins> "description": "ONLYOFFICE connector allows you to view, edit and collaborate on text documents, spreadsheets and presentations within Nextcloud using ONLYOFFICE Docs. This will create a new Edit in ONLYOFFICE action within the document library for Office documents. This allows multiple users to co-author documents in real time from the familiar web interface and save the changes back to your file storage.", "homepage": "https://www.onlyoffice.com", "licenses": [

Discussion:
The nextcloud package set offers apps, that have licensing information attached, but not exposed as part of their meta attribute. Also, there are some apps, like news, where the licensing information says , which requires clarification. This needs to be fixed.
Thank you for opening the draft PR in order to fix my mistakes and broken packages. I'm sorry for the bad communication and the inability to resolve this serious issue. Fixing this for Wordpress packages and themes (wp4nix) and Nextcloud apps (nc4nix) in a foreseeable time exceeds my skills and competence. Therefore I would like to offer to add a flag to these package sets and remove them for the next release 23.11 if it's not resolved by then.
Change:
# ~/.cache/vimfiles/repos vimrcConfig.packages.myVimPackage = with vimPlugins; { start = [ ]; }; }; <del> spacevimdir = format.generate "init.toml" spacevim_config; </del> <ins> spacevimdir = runCommand "SpaceVim.d" { } '' mkdir -p $out cp ${format.generate "init.toml" spacevim_config} $out/init.toml ''; </ins> in stdenv.mkDerivation rec { pname = "spacevim"; version = "1.5.0";

Discussion:
Describe the bug Each time spacevim is started, the "startify" onboarding prompt is displayed, followed by an error message. To Reproduce Steps to reproduce the behavior: prompt (or or ) fails to proceed ( ) over to confirm the bug persists Expected behavior The prompt should be shown at most once at first startup. Upstream behavior would be to show it once and save in the user's home directory, nixified behavior would be to never show this and get customized configuration information from the derivation. Screenshots If applicable, add screenshots to help explain your problem. ! ! Additional context Inspection reveals that the sets to point to the generated toml file instead of a directory containing it. One approach would be to synthesize that directory with a small derivation. AFAICT does not host anything else but I could be mistaken. That being said, it gets to () so this could be used to symlink plugins maybe...? The error message is Also last month. Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(louis): nixpkgs: Maintainer information:
Change:
"solana-gossip" "solana-install" "solana-keygen" <ins> "solana-ledger-tool" </ins> "solana-log-analyzer" "solana-net-shaper" <del> "solana-sys-tuner" "rbpf-cli" </del> "solana-validator" <del> "solana-ledger-tool" "cargo-build-bpf" "cargo-test-bpf" "solana-dos" "solana-install-init" "solana-stake-accounts" "solana-test-validator" "solana-tokens" "solana-watchtower" "cargo-test-sbf" "cargo-build-sbf" </del> ] ++ [ # XXX: Ensure `solana-genesis` is built LAST! # See https://github.com/solana-labs/solana/issues/5826

Discussion:
Package name: solana-cli Latest released version: 1.16.27 <!-- Search your package here: --- Current version on the unstable channel: 1.14.23 Current version on the stable/release channel: 1.14.23 <!-- 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]:
Hello I was able make the building script work so solana-cli is updated to 1.16.27 expect solana has bug in a which doesn't let me compile. The issue was already reported back back in 22 november 2023: solana-labs/solana So until is fixed I can't do anything more, as soon as it is fixed I will post my pr
Thanks , did you manage to build it for the current version? () On the master of nixpkgs I couldn't even build the existing version of Solana due a rocksdb issue I also found this commit on homebrew PRs. Seems like they patched this part in order to make the build work:
Hello I didn't test it and I don't think I need since I made it able to compile 1.16.27 I appreciate the citation, with the patch used by them I was able to fix it, appreciate your help
Change:
stdenv.mkDerivation rec { pname = "vkd3d"; <del> version = "1.3"; </del> <ins> version = "1.4"; </ins> src = fetchurl { url = "https://dl.winehq.org/vkd3d/source/vkd3d-${version}.tar.xz"; <del> sha256 = "134b347806d34a4d2b39ea29ff1c2b38443793803a3adc50800855bb929fb8b2"; </del> <ins> sha256 = "sha256-yLqF9gSCyHPAVs9tuw6veRvIq30W1ipH83uYQbapCr0="; </ins> }; nativeBuildInputs = [ flex bison ];

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the 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: winePackages.{unstable,staging} <!-- 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: 7.10 desired version: 7.12 <!-- 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.
cc
PR at , needs to be tested still. My last attempts at updating have been held back by the fact that there are so many variants that building everything is prohibitively time consuming on my machine, and PRs that were ready have been lingering so long that I've had to update them with one or two even newer wine versions before they were merged, so I was not particularly motivated.
Change:
<del> { stdenv, fetchurl, pam, python3, libxslt, perl, ArchiveZip, gettext </del> <ins> { stdenv, fetchurl, fetchpatch, pam, python3, libxslt, perl, ArchiveZip, gettext </ins> , IOCompress, zlib, libjpeg, expat, freetype, libwpd , libxml2, db, curl, fontconfig, libsndfile, neon , bison, flex, zip, unzip, gtk3, gtk2, libmspack, getopt, file, cairo, which

Discussion:
Describe the bug Using commit . See build output . Not sure who the maintainer is as no on github, so pinging recent committers
Guessing that poppler update broke it:
cc
One possibility to fix this would be to use : ... haven't finished compiling but seems to work. Other possibility is to use bundled version of poppler (0.74): ... haven't tested this at all. I don't have fast machine to test this quickly, can someone perhaps ask the bot to build these?
ArchLinux uses this patch Can you try it?
I thing the best option is using upstream patch
Building now
my maintainer handle is simply older than GitHub migration, it is in , though
Change:
stdenv.mkDerivation rec { pname = "i3"; <del> version = "4.18.2"; </del> <ins> version = "4.18.3"; </ins> src = fetchurl { url = "https://i3wm.org/downloads/${pname}-${version}.tar.bz2"; <del> sha256 = "030jym6b8b07yf4y6pb806hg8k77zsprv569gy0r72rh5zb1g1mj"; </del> <ins> sha256 = "03dijnwv2n8ak9jq59fhq0rc80m5wjc9d54fslqaivnnz81pkbjk"; </ins> }; nativeBuildInputs = [ which pkgconfig makeWrapper installShellFiles ];

Discussion:
I upgraded to 20.09 beta today, and on login, network-manager-applet crashes: ` This did no use happen on 20.03. I saw this with ibus once, but it does not reproduce reliably, and maybe it's something else. Note that the bug is twofold: first nm crashes, but the unit does not have . Restarting the unit by hand works perfectly. Login to your x session. This happened to me in a xfce+i3 session, not sure if it's relevant. system: host os: multi-user?: sandbox: version: channels(root): channels(symphorien): channels(foo): nixpkgs: cc nm applet module maintainers
I also see this with i3 and nm-applet. I use . And the same is reported by application: If needed, I can try to get the backtrace.
I can trigger this crash not only on login, but also by restarting i3 window manager or by changing xrandr configuration. In my case, the login crash was caused by calling xrandr from i3 config.
Indeed changing the resolution in xfce parameters crashes nm-applet.
This was fixed in i3 upstream by or I no longer have the issue with i3 4.18.3.
This requires a backport to 20.09 as far as I can tell
This is long fixed by in . It looks like I cannot close this issue.
Change:
kernel-latest = handleTest ./kernel-latest.nix {}; kernel-lts = handleTest ./kernel-lts.nix {}; kernel-testing = handleTest ./kernel-testing.nix {}; <ins> keycloak = discoverTests (import ./keycloak.nix); </ins> keymap = handleTest ./keymap.nix {}; knot = handleTest ./knot.nix {}; krb5 = discoverTests (import ./krb5 {});

Discussion:
Project description Metadata homepage URL: source URL: license: Apache-2.0 platforms: linux, darwin (maybe?)
There exists a package: A module is currently missing.
Uh I was pretty sure I checked in my local nixpkgs checkout. Weird, I wonder if I just made a typo while checking. Sorry about that. We can leave this issue for the module part.
It looks like the maintainer is Have you started work on a module already, or would you prefer someone else step up to work on that part? I haven't dealt with creating modules in the past, but I'd be willing to learn.
I haven't dug into making a module previously. I suspect there's a bit of ugliness around the setup and configuration decoratively, but I'm happy to work with someone on it. Shall I start a basic PR?
yes please :)
Change:
stdenv.mkDerivation rec { name = "gtkd-${version}"; <del> version = "3.6.5"; </del> <ins> version = "3.8.3"; </ins> src = fetchzip { url = "https://gtkd.org/Downloads/sources/GtkD-${version}.zip"; <del> sha256 = "1ypxxqklad5wwyvc39wnphnqp5y4q5zbf9j5mxb3bg9vnls48vx1"; </del> <ins> sha256 = "10jhwy1421bypq62ki1dzv8irvlgwr7s40z6l6vxallm4jkgk9gj"; </ins> stripRoot = false; };

Discussion:
Tilix allows changing its window title by simply clicking on the title itself in the titlebar. Then the title must be replaced by an input box. Instead of that, Tilix segfaults. Install Tilix. Launch Tilix. Click on Tilix titlebar. system: host os: multi-user?: sandbox: version: nixpkgs:
Change:
couchdb = handleTest ./couchdb.nix {}; crabfit = handleTest ./crabfit.nix {}; cri-o = handleTestOn ["aarch64-linux" "x86_64-linux"] ./cri-o.nix {}; <ins> cryptpad = runTest ./cryptpad.nix; </ins> cups-pdf = handleTest ./cups-pdf.nix {}; curl-impersonate = handleTest ./curl-impersonate.nix {}; custom-ca = handleTest ./custom-ca.nix {};

Discussion:
Project description CryptPad is a collaborative office suite that is end-to-end encrypted and open-source. Enable this a service for NixOS. Metadata homepage URL: source URL: license: agpl2 platforms: unix, linux, darwin, ...
CryptPad used to be included in nixpkgs, but it was removed because there weren't enough maintainers. The removal occurred with the commits and .
Not quite true: it was removed because they had a strong dependency on out-of-date software. . Now, there is an ongoing effort to re-introduce it in : .
Change:
"test_precentered_2" ]; <ins> # these files import distutils # remove once https://github.com/mdtraj/mdtraj/pull/1916 is merged disabledTestPaths = lib.optionals (pythonAtLeast "3.12") [ "test_mol2.py" "test_netcdf.py" ]; </ins> pythonImportsCheck = [ "mdtraj" ]; meta = with lib; {

Discussion:
system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
objectClass: organizationalUnit ou: users ''; <ins> ldapClientConfig = { enable = true; loginPam = false; nsswitch = false; server = "ldap://"; base = "dc=example"; }; </ins> testScript = '' machine.wait_for_unit("openldap.service") machine.succeed( <del> 'ldapsearch -LLL -D "cn=root,dc=example" -w notapassword -b "dc=example"', </del> <ins> 'ldapsearch -LLL -D "cn=root,dc=example" -w notapassword', </ins> ) ''; in {

Discussion:
The system-wide LDAP client configuration in is ignored by Openldap client programs. Steps to reproduce the behavior: settings into via or any other Openldap client Openldap client programs should obey the system-wide configuration file in . strace shows it's reading the example configuration from the package instead: Since commit the openldap package no longer passes to configure, it only passes to make instead. Please run and paste the result.
It seems a bit dodgy, but this might be a solution: plus corresponding changes to all the packages and tests that refer to . I'm just rebuilding a gazillion packages on my system from source, so I can check if that works properly...
you probably meant to ping and instead
Oops, sorry about that. I forgot that the maintainer handles listed in the package do not necessarily correspond to their Github usernames.
I realised that changing is probably unwise. Not only does it break some other packages (like python-ldap) and some Nixos tests, it will also break any users who have configured slapd to refer to the schemas under , as I myself have: And changing is not necessary to fix the bug anyway. It seems that the approach of passing differently in compile and install works. I'll send a PR for it.
Change:
dbus-python gtts pygobject3 <ins> beautifulsoup4 </ins> ]; # Prevent double wrapping, let the Python wrapper use the args in preFixup.

Discussion:
Translation fails using any of the available providers, thus rendering it useless: Google API as per below LibreTranslate API immediately shows a full-window error as per screenshot Lingva API immediately shows a full-window error as per screenshot Steps to reproduce the behavior: anything I expect a translator to be able to translate. ! ! ! is also available.
It seems this is already known.
Change:
<xi:include href="coq.section.xml" /> <xi:include href="crystal.section.xml" /> <xi:include href="emscripten.section.xml" /> <del> <xi:include href="gnome.xml" /> </del> <ins> <xi:include href="gnome.section.xml" /> </ins> <xi:include href="go.section.xml" /> <xi:include href="haskell.section.xml" /> <xi:include href="idris.section.xml" />

Discussion:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! in this issue that you intend to work on it. (Please also post if you stop working on it) a new branch of nixpkgs master. : change to . the contents from Docbook to . Follow . Use existing sections for inspiration. the contents from Docbook to . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
I can try to tackle this, hopefully we will be able to figure out how to make it functionally equivalent, even if semantic equivalence is out.
I want to finish first to avoid conflicts, though.
This was merged now.
Change:
mktplcRef = { name = "direnv"; publisher = "mkhl"; <del> version = "0.13.0"; sha256 = "sha256-KdLJ7QTi9jz+JbbQuhXqyE3WV9oF+wyC/9ZJ/XTFOYc="; </del> <ins> version = "0.14.0"; sha256 = "sha256-T+bt6ku+zkqzP1gXNLcpjtFAevDRiSKnZaE7sM4pUOs="; </ins> }; meta = { description = "direnv support for Visual Studio Code";

Discussion:
Package name: vscode- Latest released version: 0.14.0 Current version on the unstable channel: 0.13.0 Current version on the stable/release channel: 0.12.0 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Change:
CoreGraphics Foundation libiconv <ins> System </ins> UserNotifications ]; buildFeatures = [ "distro-defaults" ]; <ins> env.NIX_LDFLAGS = lib.optionalString stdenv.isDarwin "-framework System"; </ins> postInstall = '' mkdir -p $out/nix-support echo "${passthru.terminfo}" >> $out/nix-support/propagated-user-env-packages

Discussion:
Steps to reproduce the behavior: for , on MacOS Ventura (13.3.x) Tested builds on both a and an and got the same error. Metadata was obtained on an machine compiling for both architectures, as x86 Darwin can be compiled for on Apple Silicon. Please run and paste the result.
No idea and I am not really motivated to dig into why this is broken myself. If someone figures it out, please fill a PR and I'll take a look at it.
FYI, the sdk versions may be bad.
We are using the 11 sdk since maybe some dependency also needs to be linked against that version? /cc
Is there a way to choose the binary package instead of building from source?
I am having the same issue since I last updated my flakes.
On MacOS you can download the wezterm binary from their page.
Until this is fixed I've replaced the derivation with the . Working great so far.