jiebi/CodeConvo huggingface dataset:
Code change:
mv courbd.ttf    Courier_New_Bold.ttf mv couri.ttf     Courier_New_Italic.ttf mv courbi.ttf    Courier_New_Bold_Italic.ttf <del> mv georgia.ttf   Georgia.ttf </del> <ins> mv georgia.ttf   Georgia.ttf.tmp mv Georgia.ttf.tmp   Georgia.ttf </ins> mv georgiab.ttf  Georgia_Bold.ttf mv georgiai.ttf  Georgia_Italic.ttf mv georgiaz.ttf  Georgia_Bold_Italic.ttf <del> mv impact.ttf    Impact.ttf mv tahoma.ttf    Tahoma.ttf </del> <ins> mv impact.ttf    Impact.ttf.tmp mv Impact.ttf.tmp    Impact.ttf mv tahoma.ttf    Tahoma.ttf.tmp mv Tahoma.ttf.tmp    Tahoma.ttf </ins> mv times.ttf     Times_New_Roman.ttf mv timesbd.ttf   Times_New_Roman_Bold.ttf mv timesbi.ttf   Times_New_Roman_Bold_Italic.ttf

Related discussion:
text: Steps to reproduce the behavior: macOS: Since , this fails on macOS due to case-insensitivity (). The offending PR had no description, no reviews and no reports of tests on any platform. It was merged by the author four days after it was opened. Please run and paste the result.
Fuck MacOS and their stupid case insensitive file system.
Can you try mv'ing the file first to another name like?
Code change:
# determine the version number, there might be different ones per architecture version = { <del> x86_64-linux = "19.16.0.0.0"; </del> <ins> x86_64-linux = "21.9.0.0.0"; </ins> aarch64-linux = "19.10.0.0.0"; <del> x86_64-darwin = "19.3.0.0.0"; </del> <ins> x86_64-darwin = "19.8.0.0.0"; </ins> }.${stdenv.hostPlatform.system} or throwSystem; directory = { <del> x86_64-linux = "1916000"; </del> <ins> x86_64-linux = "219000"; </ins> aarch64-linux = "191000"; <del> x86_64-darwin = "193000"; </del> <ins> x86_64-darwin = "198000"; </ins> }.${stdenv.hostPlatform.system} or throwSystem; # hashes per component and architecture hashes = { x86_64-linux = { <del> basic = "sha256-Sq1rWvbC1YME7EjSYPaP2g+1Xxxkk4ZkGaBmLo2cKcQ="; sdk = "sha256-yJ8f/Hlq6vZoPxv+dfY4z1E7rWvcqlK+ou0SU0KKlEI="; sqlplus = "sha256-C44srukpCB9et9UWm59daJmU83zr0HAktnWv7R42Irw="; tools = "sha256-GP4E1REIoU3lctVYmLsAiwTJEvGRpCmOFlRuZk+A8HE="; odbc = "sha256-JECxK7Ia1IJtve2goZJdTkvm5NJjqB2rc6k5BXUt3oA="; </del> <ins> basic = "sha256-wiygUvZFYvjp5pndv3b9yTPxe8sC5HZkJ7jZqO1Mss8="; sdk = "sha256-ehqHV52yLRe8ehrKqpLaN0HnN3zjHU7WrfjtqvQadgY="; sqlplus = "sha256-tYvoG+7l5jXyTpxFUYZXaHCT0xGDeah78AinJ2qIsE8="; tools = "sha256-6K2Ni0ZqqpqCrGFrBD06s0QNjNEDtNPrvDQ1U97lTKY="; odbc = "sha256-yTANMLhaEqm9/ZEVqhEn1Gl8eJukgvqpqdaMRjxWxgs="; </ins> }; aarch64-linux = { basic = "sha256-DNntH20BAmo5kOz7uEgW2NXaNfwdvJ8l8oMnp50BOsY=";

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:
stopNest } <ins> patchShebangsAuto () { if [ -z "$dontPatchShebangs" -a -e "$prefix" ]; then # Dev output will end up being run on the build platform. An # example case of this is sdl2-config. Otherwise, we can just # use the runtime path (--host). if [ "$output" != out ] && [ "$output" = "${!outputDev}" ]; then patchShebangs --build "$prefix" else patchShebangs --host "$prefix" fi fi } </ins>

Related discussion:
text: uses to determine the substitute for the shebang path. This selects the wrong path during cross-builds and results in x8664 binaries getting pulled in as dependencies to cross-built binaries that can't possibly use them at runtime. I don't know if we can reliably pick the correct /bin/sh without it being in the PATH envvar. I presume patchShebangs works fine for binaries that don't overlap with stdenv's and are included in buildInputs. If you cross-build some packages to ARM platforms, patchShebangs runs in the fixup phase and run , you'll see it points to the native /bin/sh rather than the cross one. I was considering a PR to just add to the cross build of glibc, but figured it'd be better if the root issue were fixed instead. System: "16.03pre75806." Nix version: nix-env (Nix) 1.12pre1234abcdef Nixpkgs version: (Gorilla)
/participate. (I've stumbled across this too.)
Is it safe to assume are the only paths that will ever realistically have this problem? If so, how and where would we pull in as a buildInput without it clobbering the native /bin/sh used by stdenv to run the builder? Once we're already executing , it's too late to find any s. This problem overlaps with another, , which is that crossDrvs clobber stdenv's binaries in the PATH. The best solution I can come up with is to manually include in of e.g. glibc, add logic in to not add to the PATH when crossbuilding, based on some new derivation attr like , then search during , independently of what's set in the PATH. Or we could just make smarter about importing /bin/ PATHs that contain elements of the stdenv, namely: .
is essential to fix this without greatly complicating bootstrapping.
don't forget to close. :)
Addressed in
Code change:
<ins> { lib, python3Packages, fetchFromGitLab, gobject-introspection, wrapGAppsHook4, libadwaita, }: python3Packages.buildPythonApplication rec { pname = "turtle"; version = "0.8"; pyproject = true; src = fetchFromGitLab { domain = "gitlab.gnome.org"; owner = "philippun1"; repo = "turtle"; rev = version; hash = "sha256-YacuT5S6WrhSz031XXCQTo++r+DBozrIIXrn9BwmrR0="; }; postPatch = '' substituteInPlace ./install.py  --replace-fail "/usr" "$out"  --replace-fail "gtk-update-icon-cache" "gtk4-update-icon-cache" ''; nativeBuildInputs = [ gobject-introspection wrapGAppsHook4 ]; buildInputs = [ libadwaita ]; build-system = with python3Packages; [ setuptools ]; dependencies = with python3Packages; [ pygobject3 pygit2 ]; postInstall = '' python ./install.py install ''; # Avoid wrapping two times dontWrapGApps = true; # Make sure we patch other scripts after wrapper is generated # to get $program_PYTHONPATH dontWrapPythonPrograms = true; postFixup = '' makeWrapperArgs+=(''${gappsWrapperArgs[@]}) wrapPythonPrograms '' # Dialogs are not imported, but executed. The same does # nautilus-python plugins. So we need to patch them as well. + '' for dialog_scripts in $out/lib/python*/site-packages/turtlevcs/dialogs/*.py; do patchPythonScript $dialog_scripts done for nautilus_extensions in $out/share/nautilus-python/extensions/*.py; do patchPythonScript $nautilus_extensions done ''; meta = { description = "A graphical interface for version control intended to run on gnome and nautilus"; homepage = "https://gitlab.gnome.org/philippun1/turtle"; license = lib.licenses.gpl3Plus; mainProgram = "turtle_cli"; maintainers = with lib.maintainers; [ aleksana ]; platforms = lib.platforms.unix; }; } </ins>

Related discussion:
text: Project description Turtle is a graphical interface for version control intended to run on gnome and nautilus. Currently these dialogs are implemented: commit, add, stage, unstage, revert, resolve sync (pull+push), pull, push checkout, create branch init, clone remotes, submodules log, diff settings and about Metadata homepage URL: source URL: license: gpl3+ platforms: linux
Code change:
Linux kernels that provide EFI stub support. ''; homepage = "http://refind.sourceforge.net/"; <del> maintainers = with maintainers; [ AndersonTorres samueldr ]; </del> <ins> maintainers = with maintainers; [ AndersonTorres samueldr chewblacka ]; </ins> platforms = [ "i686-linux" "x86_64-linux" "aarch64-linux" ]; license = licenses.gpl3Plus; };

Related discussion:
text: efibootmgr is not a dependency, despite being needed Steps to reproduce the behavior: refind refind-install the error message: ! efibootmgr is a dependency of refind I already had refind installed (from another distro) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
glfw openal stdenv.cc.cc.lib <del> ]; </del> <ins> ] ++ lib.optional gamemodeSupport gamemode.lib); </ins> in [ "--set LD_LIBRARY_PATH /run/opengl-driver/lib:${libpath}"

Related discussion:
text: A clear and concise description of what the bug is. Prism Launcher doesn't allow enabling Feral GameMode or MangoHud under the "Performance" tab because it can't find it. Steps to reproduce the behavior: GameMode ( ) MangoHud ( ) Prism Launcher ( ) new instance in Prism Launcher instance and go to "Performance" tab A clear and concise description of what you expected to happen. GameMode and MangoHud should be able to be enabled when installed. If applicable, add screenshots to help explain your problem. ! ! 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.
Addressed here -
Code change:
cp -p ${spath}/certificates/${keyName}.issuer.crt chain.pem ln -s fullchain.pem cert.pem cat key.pem fullchain.pem > full.pem <del> chmod ${rights} *.pem chown '${data.user}:${data.group}' *.pem </del> fi <ins> chmod ${fileMode} *.pem chown '${data.user}:${data.group}' *.pem </ins> ${data.postRun} ''; in

Related discussion:
text: Describe the bug If I change and enable when the cert/key in question already exists the group access will not be granted after rebuilding and restarting the . This is because a condition in the post start script does so only when the key is newer than the existing one. To Reproduce Steps to reproduce the behavior: without group/allowKeysForGroup and start the service to reques the certificate group and allowKeysForGroup again and restart the service, the ownership/ode will not be updated Expected behavior The group and chmod setting should be set on existing certificates as well as new ones. Metadata Please run and paste the result. Maintainer information:
Additionally, shouldn't chmod 0640 suffice on the files?
cc as potentially interested individuals
Code change:
environment.systemPackages = lib.mkIf (cfg.keybindings || cfg.fuzzyCompletion) [ pkgs.fzf ]; programs = { <del> bash.interactiveShellInit = lib.optionalString cfg.fuzzyCompletion '' </del> <ins> # load after programs.bash.enableCompletion bash.promptPluginInit = lib.mkAfter (lib.optionalString cfg.fuzzyCompletion '' </ins> source ${pkgs.fzf}/share/fzf/completion.bash '' + lib.optionalString cfg.keybindings '' source ${pkgs.fzf}/share/fzf/key-bindings.bash <del> ''; </del> <ins> ''); </ins> zsh = { interactiveShellInit = lib.optionalString (!config.programs.zsh.ohMyZsh.enable)

Related discussion:
text: The last fzf update in nixos-unstable breaks certain bash-completions, for example git. This happens since Then try bash completion for git. My looks like this <details</detailsThe regular bash completions for git should work. As a fix I found this old issue in fzf To test this, I tried simply replacing with an edited version that puts the fzf eval after the bash completions code (and before the alias declarations). This fixes the issue. However, I am not sure how to solve this cleanly in NixOS. The bash completion code is inserted using but I don't know how to enforce ordering so that the fzf eval happens after the completions. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for the report, I started a PR super-seeded by fixing this issue. As what I found this issue was already there previously but as most people didn't had the full integration enabled it didn't triggered the issue.
Is there any progress on this? Solution PRs seem to have been closed?
The fix already got merged and will be soon on unstable - otherwise you might cherry-pick/overlay it.
Cool, so we can close this presumably?
I looked at this in master and now we're basically back to how the fzf module was previously, right? So then it should still be an issue when enabling .
Alright, so now I'm just gonna try my luck with a PR. It definitely works for me and makes a difference.
Code change:
}: stdenv.mkDerivation rec { <del> pname = "cjs"; version = "4.6.0-gjs-1.66.0"; </del> <ins> pname = "cjs-unstable"; version = "2020-10-19"; </ins> src = fetchFromGitHub { <del> owner = "leigh123linux"; repo = pname; rev = "gjs-1.66.0"; sha256 = "1pccz7h8mwljziflhn04gmfnbl99pvcj1byz1c6zn947v5gqskj1"; </del> <ins> owner = "linuxmint"; repo = "cjs"; rev = "befc11adb5ba10681464e6fa81b1a79f108ce61c"; hash = "sha256-F2t8uKV2r29NxX2+3mYp5x1bug2lwihJZTK1dSS8rPg="; </ins> }; outputs = [ "out" "dev" ];

Related discussion:
text: of repo is a branch, not a tag, and there were a few commits to that branch since then. At the moment fresh fetching of source is broken because of wrong : it should be now . should probably be pointed to a specific commit, not a branch? Originally posted by in
Code change:
inherit (darwin.apple_sdk.frameworks) ApplicationServices; }; <del> pangox_compat = callPackage ../development/libraries/pangox-compat { }; </del> gdata-sharp = callPackage ../development/libraries/gdata-sharp { }; gdk-pixbuf = callPackage ../development/libraries/gdk-pixbuf { };

Related discussion:
text: Describe the bug Seems like some updates to pango broke a few packages Among the broken ones: ettercap (see ) pangox-compat (which anydesk needs) probably a few more To Reproduce Steps to reproduce the behavior: to build ettercap or anydesk from master will fail to build with some pango-related errors Expected behavior It should work Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata system: host os: multi-user?: sandbox: version: channels(maciej): nixpkgs: Maintainer information:
Also remmina is broken But doesn't seem to depend on pango directly, so unsure which dependency actually is broken
Here's an issue for pangox-compat
Lutris is broken too - not an urgent requirement but just making you fine folks aware!
Not sure why Lutris is broken, but Lutris-unwrap is fine.
It's a failure in the dependency chain, in this case .
no longer depends on on its master branch: We should probably switch to that. should not be needed in according to the README in , I suspect it was only there because we did not propagate it until ebassi also suggests switching to HEAD and says we need not worry about ABI changes:
Not having pangox_compat fixed is definitively still an issue. Can this be re-opened?
After , the only program depending on this is anydesk and openmodelica which is broken.
So it breaks anydesk thus either we mark anydesk as broken or we fix that?
Anydesk shouldn't use this deprecated library. Yes, we can mark it as broken.
Code change:
, liblogging ? null, libnet ? null, hadoop ? null, rdkafka ? null , libmongo-client ? null, czmq ? null, rabbitmq-c ? null, hiredis ? null, mongoc ? null , libmaxminddb ? null <ins> , nixosTests ? null </ins> }: with stdenv.lib;

Related discussion:
text: Describe the bug Test  is broken on Master To Reproduce Steps to reproduce the behavior: Expected behavior For the test to pass Additional context I've bisected the problem to this commit:
Thank you for opening this :sparkles:
In that case let's it.
That is weird. How does depend on rsyslog?
This test is kind of flaky, there's some chance I incorrectly bisected it?
I'm bisecting again starting at
going to plug :grin: At a glance I don't see rysyslog having any relation, and likely if the tests are flakey enough bisecting can't give reliable results.
I didn't use that tool because I was bisecting by running the test thrice and only if all fail considering it a bad commit :P
cc. maybe add a flag to :P
That kind of unforseen usecase is exactly why nix-bisect is not just a tool, but a library ;) So you could write your own bisect script in python (a much more pleasant experience than doing so in bash). I may add that feature to the CLI at some poing though, since its probably a pretty common usecase. would probably be a better name, since we really want a minimum number of tries. Feel free to file an issue against :)
I tried bisecting again, but I think this result is also nonsense:
Core of the issue seems to be this:
I don't know &ndash; locally I'm getting this :arrow_up: error even on which (I tried several times).
Careful (manual) bisect lead me to a surprising result: I'll try a few more experiments now. Many my steps failed for other reasons (e.g. libselinux not building), so I suspect that's where you were led astray. I did 2-3 attempts on every step to be surer, but I found no non-determinism on my machine.
I had quite a few steps where the first attempt at building failed, but the second one succeeded, I was bisecting manually with this:
I re-confirmed that reverting that commit atop master () fixes the test for me. (Still no idea why so far.)
cc for the linux config change
Narrowed down just to the kernel option. I don't know... maybe the JIT has some bad interaction with the VM.
Code change:
, liblogging ? null, libnet ? null, hadoop ? null, rdkafka ? null , libmongo-client ? null, czmq ? null, rabbitmq-c ? null, hiredis ? null, mongoc ? null , libmaxminddb ? null <ins> , nixosTests ? null </ins> }: with stdenv.lib;

Related discussion:
text: For now I suppose I'll push a revert of that single option, unless someone suggests a better idea very soon.
Sounds good to me
Code change:
luaevent,,,,,, luaexpat,,,,1.4.1-1,,arobyn flosse luaffi,,,http://luarocks.org/dev,,, <del> luafilesystem,,,,1.7.0-2,,flosse </del> <ins> luafilesystem,,,,1.8.0-1,,flosse </ins> lualogging,,,,,, luaossl,,,,,5.1, luaposix,,,,34.1.1-1,,vyp lblasc

Related discussion:
text: Version 1.8.0 is available and . It looks like this should be a trivial bump in the luarocks csv. <!-- 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: <!-- 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: 1.7.0-2 desired version: 1.8.0-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.
Wanna take a stab at it then ? we can help you through the process
Code change:
}; mesaPackage32 = mkOption { type = types.package; <del> default = pkgs.pkgsi686Linux.mesa_23; defaultText = literalExpression "pkgs.pkgsi686Linux.mesa_23"; </del> <ins> default = pkgs.pkgsi686Linux.mesa; defaultText = literalExpression "pkgs.pkgsi686Linux.mesa"; </ins> example = literalExpression "pkgs.pkgsi686Linux.mesa_22"; description = lib.mdDoc '' Same as {option}`mesaPackage` but for the 32-bit Mesa on 64-bit

Related discussion:
text: The laptop screen freezes with the current contents (systemd startup messages) at the point starts. Nothing else visible happens. I can switch VT's back to text consoles, switching back to VT7 again just freezes the display. All the normal processes seem to be running, but they don't draw anything. I'm using gnome and wayland. Updated to today's () Booted previous system generation, was working again. With some excellent help on Matrix from I have confirmed that: building from previous branch revision () and switching (no reboot) makes gdm work again. building from current revision () with also works. building from the previous revision with that line fails to evaluate, because the multi-version package change isn't there yet. So / are clearly implicated. K900 suggested raising this as an upstream Mesa bug. I had some issues registering there, but may try again later and will add a link here in case system: host os: multi-user?: sandbox: version: channels(root): channels(dan): nixpkgs: bits of relevant config: note that the displaylink driver is not in use (no device connected) at this point, it's all on the internal display only. Hardware is a Dell XPS 13 9360
Code change:
}; mesaPackage32 = mkOption { type = types.package; <del> default = pkgs.pkgsi686Linux.mesa_23; defaultText = literalExpression "pkgs.pkgsi686Linux.mesa_23"; </del> <ins> default = pkgs.pkgsi686Linux.mesa; defaultText = literalExpression "pkgs.pkgsi686Linux.mesa"; </ins> example = literalExpression "pkgs.pkgsi686Linux.mesa_22"; description = lib.mdDoc '' Same as {option}`mesaPackage` but for the 32-bit Mesa on 64-bit

Related discussion:
text: If gdm is enabled with Gnome enabled, gdm will crash and not load into the login screen after logout or reboot. This is due to gdm using wayland as the default. Once wayland is disabled in gdm, the login works. Steps to reproduce the behavior: channel nixos-unstable, "sudo nixos-rebuild switch upgrade-all" with Gnome enabled and gdm enabled in will hang at the gdm check point. gdm wayland in and the reboot works but with Wayland not working. Reboot into gdm with Wayland <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I just hit the same issue. After updating to latest nixos-unstable, the boot hangs just before login screen I think this is related to , at least the workaround posted there worked for me also
Would be relevant with a machine without AMD graphics and without KDE? As, I am running Intel's build in graphics and using Gnome. Also, I did find a "workaround" by disabling wayland in gdm then nixos-unstable will boot.
I managed to work around this issue with on GNOME Wayland. Graphic card: Intel Xe Graphics (TGL GT2)
Totally worked! Thanks and ! Should I leave this open as this is a bug or a new config that needs to be applied to 23.05?