jiebi/CodeConvo huggingface dataset:
Code change:
homepage = https://postgis.net/; license = licenses.gpl2; maintainers = [ maintainers.marcweber ]; <del> platforms = platforms.linux; </del> <ins> inherit (postgresql.meta) platforms; </ins> }; }

Related discussion:
text: Describe the bug has , preventing it from being used on other platforms, particularly Darwin in my case. To Reproduce nix-shell to get this error: error: Package ‘postgis-2.5.2’ in is not supported on ‘x8664-darwin’, refusing to evaluate. Expected behavior Produce a postgresql-and-plugins package with postgis available. Additional context Simply allowing doesn't work immediately because PostGIS' build system is quirky. There was some relevant-looking discussion on . Metadata system: host os: multi-user?: sandbox: version: channels(lukeworth): nixpkgs:
Code change:
./fix-122159.patch # https://github.com/NixOS/nixpkgs/issues/122159 ]; <ins> # Note: xposix is renamed to posix in v5. postPatch = lib.optionalString stdenv.isLinux '' substituteInPlace xpra/platform/xposix/features.py  --replace-fail "/usr/bin/xdg-open" "${xdg-utils}/bin/xdg-open" ''; </ins> INCLUDE_DIRS = "${pam}/include"; nativeBuildInputs = [

Related discussion:
text: Xpra supports forwarding invocations from the server to the client. The Xpra client defaults to hardcoding as the command to invoke on the client, which does not exist in NixOS. This bug does not impact hosts other than NixOS. Steps to reproduce the behavior: somehow. The Xpra client should invoke the local . N/A. This could be fixed by setting the open command to just , but it might match the intent better to change it to something like perhaps. Presumably, the point of doing it this way is to avoid any other copies of that might appear on the , e.g. Xpra's own. I suppose we can't really rely on to exist: even if we could on NixOS, we can't on other Linux distributions running Nix, where might make more sense. It seems to me that the best compromise, then, is to hardcode a path to copy of and users can override this using the option if needed. The open command that Xpra uses is configurable on the client-side, but the default is set as a platform-specific variable. On Linux, it is set in . Because there are separate values for both Windows and Darwin hosts, patching the value to shouldn't ever break them (but of course it should still be a Linux-specific patch, otherwise it unnecessarily brings into the closure.) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
let pname = "osu-lazer-bin"; <del> version = "2024.312.0"; </del> <ins> version = "2024.312.1"; </ins> src = { aarch64-darwin = fetchzip { url = "https://github.com/ppy/osu/releases/download/${version}/osu.app.Apple.Silicon.zip"; <del> hash = "sha256-RwOSB/WcAqR8j0xw1QUji1IEn7iHXcHj2xOcKjnpl00="; </del> <ins> hash = "sha256-1MsZ9gHTZKArXk1b6XEBNk/ZWAUHKjbVrrn++dLulaQ="; </ins> stripRoot = false; }; x86_64-darwin = fetchzip { url = "https://github.com/ppy/osu/releases/download/${version}/osu.app.Intel.zip"; <del> hash = "sha256-Wnr7CtQIfugKrGsl72NXdHJIsF7rRNhzjV1Q+gRHK10="; </del> <ins> hash = "sha256-Xgl8lrMsL9O9YHbEx3Iwwh9fpLOnYZN0Kt28F5X5OwE="; </ins> stripRoot = false; }; x86_64-linux = fetchurl { url = "https://github.com/ppy/osu/releases/download/${version}/osu.AppImage"; <del> hash = "sha256-kWNobQXGGS2TWvPkhfheqnlbijfnxfcP36ANUeN6bW0="; </del> <ins> hash = "sha256-1dzgs1p3/pf4eCdKvQ9JxowN+oBPBNaZv5e6qHeFPEM="; </ins> }; }.${stdenv.system} or (throw "${pname}-${version}: ${stdenv.system} is unsupported.");

Related discussion:
text: Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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]:
Code change:
<del> { stdenv, lib, fetchFromGitHub, kernel, writeScript, coreutils, gnugrep, jq, curl, common-updater-scripts, runtimeShell </del> <ins> { stdenv , lib , fetchFromGitHub , fetchpatch , kernel , writeScript , coreutils , gnugrep , jq , curl , common-updater-scripts , runtimeShell </ins> }: stdenv.mkDerivation rec {

Related discussion:
text: Steps to reproduce the behavior: on old thinkpad Device: Thinkpad X220 <!-- 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.
greetings ! are you able to test ? an other workaround is to stick to < 6.4 kernel
for now I can't test your commit since I'm newbie and asking you to teach me would take a lot of your time Gonna stick to < 6.4 kernel and try to test commit in free time
appreciate your concerns! from looking at your setup you seem to know fair bit already, and I dont mind spending some time for as long we all learn something useful you should be able to test that PR by changing in your flake to edit: also no rush to test this
Well that was actually easy to test! PR works! I thought I need to use overlays to test it and I have zero experience with them for now.
Code change:
, newuidmapPath ? null # Path to SUID-ed newgidmap executable , newgidmapPath ? null <ins> # External LOCALSTATEDIR , externalLocalStateDir ? null </ins> # Remove the symlinks to `singularity*` when projectName != "singularity" , removeCompat ? false # Workaround #86349

Related discussion:
text: The derivation is missing the directory to work properly. Steps to reproduce the behavior: A clear and concise description of what you expected to happen. is output without error. This can be fixed by creating the directory manually (). I guess this could be to the derivation. <!-- 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.
NixOS module provides those top-level directories. discussed with one of the main Apptainer developer in . He think it should be easy to specify a directory that will always exist at build time. Regalding this, I'm considering the possibility to put those dilectories under the derivation store path. Not sure if there would be potential problem using a store path as a mount point, but it seems to work without problem.
Could you help me take a look at ?
If you have time, please help me test the PR . It should fundamentally solve this issue. If applied, you no longer need the NixOS module or just to run images. It specifies the LOCALSTATEDIR as , making both Apptainer and Sylabs SingularityCE works without . (The image running still depends on and to run images, which might be the final obstacle to build images as a package without invoking a virtual machine. Other than that, it should not be an issue for most users, as are available on most of the UNIX/UNIX-like systems.)
I removed (the temporary fix for this issue) and ran the following and it seems to work fine: Thank you for this fix!
Glad to hear that! Would you mind ? I've heard that committers tend to merge PRs getting two approvals.
Done!
Code change:
checkInputs = [ sphinx numpydoc pytest ]; propagatedBuildInputs = [ python-lz4 ]; <del> # test_disk_used is broken # https://github.com/joblib/joblib/issues/57 </del> <ins> # test_disk_used is broken: https://github.com/joblib/joblib/issues/57 # test_dispatch_multiprocessing is broken only on Darwin. </ins> checkPhase = '' <del> py.test joblib -k "not test_disk_used" </del> <ins> py.test -k 'not test_disk_used${lib.optionalString (stdenv.isDarwin) " and not test_dispatch_multiprocessing"}' joblib/test </ins> ''; meta = {

Related discussion:
text: Describe the bug fails on Darwin. To Reproduce Steps to reproduce the behavior: Expected behavior Package builds Additional context Error log: <details<summaryError log</summary</detailsMetadata Please run and paste the result. host os: multi-user?: sandbox: version: channels(yl): nixpkgs: Maintainer information: Possibly related to
On the master branch, I removed the derivation from the nix store with and I built it without substitutes; failed with the same message. This is not caused by , but help me discover it due to the update of the requests python package.
maintainer:
I don't have a way to test on joblib for darwin so this is why I didn't have input on this PR. Is there an easy way to test nixpkgs on darwin? Hackintosh via kvm?
There is that works with some tweaking but I wouldn't describe it as easy. Another option is to ask @ GrahamcOfBorg to do the builds on the PR if there are not too many iterations to do.
Code change:
<del> { pkgs, buildPackages, lib, gawk, gnused, gixy }: </del> <ins> { pkgs, buildPackages, lib, stdenv, libiconv, gawk, gnused, gixy }: </ins> with lib; rec {

Related discussion:
text: Describe the bug results in the following error on : Seems like the writer expects to be executed in a stdenv environment to find instead of knowing the path to it. To Reproduce Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (rust maintainers)
This should work as long as GHC is proper dep, because libiconv is propagated.
This should be independent of GHC entirely: only relation to GHC is probably that I mistook the error for one coming from GHC initially, but this is not the case ( doesn't allow building the writers individually what confused me).
I'm facing this issue trying to build from on macOS Big Sur. (wasmer is a dependency of FastAPI, which is the package I'm actually interested in) <details<summaryLogs:</summary</details
I think adding to could also help there.
Fix here:
Code change:
# and often with different versions.  We write them on three lines # like this (rather than using {}) so that the updater script can # find where to edit them. <del> versions.aarch64-darwin = "5.14.10.19202"; versions.x86_64-darwin = "5.14.10.19202"; versions.x86_64-linux = "5.15.0.4063"; </del> <ins> versions.aarch64-darwin = "5.15.2.19786"; versions.x86_64-darwin = "5.15.2.19786"; versions.x86_64-linux = "5.15.2.4260"; </ins> srcs = { aarch64-darwin = fetchurl { url = "https://zoom.us/client/${versions.aarch64-darwin}/zoomusInstallerFull.pkg?archType=arm64"; name = "zoomusInstallerFull.pkg"; <del> hash = "sha256-MK6xUkS+nX7SjIieduMhhFNqEUVdc89aPiCvHI2pjDQ="; </del> <ins> hash = "sha256-vERhyaNVxam6ypi9nU2t6RfBZgtzD6YECkSrxkxl/4E="; </ins> }; x86_64-darwin = fetchurl { url = "https://zoom.us/client/${versions.x86_64-darwin}/zoomusInstallerFull.pkg"; <del> hash = "sha256-JJ6nZ8WnTF8X8R0gIlFtsTbpdHhv65J5kWts+H3QDoM="; </del> <ins> hash = "sha256-Yx5seUks6s+NEBIxgltUQiNU3tjWpmNKMJwgAj9izh4="; </ins> }; x86_64-linux = fetchurl { url = "https://zoom.us/client/${versions.x86_64-linux}/zoom_x86_64.pkg.tar.xz"; <del> hash = "sha256-DhP6LZt/G3K9YDs7iXABsJMuhpzITP4aJ0PWXrFAL3I="; </del> <ins> hash = "sha256-R6M180Gcqu4yZC+CtWnixSkjPe8CvgoTPWSz7B6ZAlE="; </ins> }; };

Related discussion:
text: Package name: zoom-us Latest released version: 5.15.2.4260 <!-- Search your package here: --- Current version on the unstable channel: 5.15.0.4063 Current version on the stable/release channel: 5.14.7.2928 <!-- 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.
Code change:
if [ -z "$newHash" ]; then nix-build --no-out-link -A "$attr.src" 2>"$attr.fetchlog" >/dev/null || true # FIXME: use nix-build --hash here once https://github.com/NixOS/nix/issues/1172 is fixed <del> newHash=$(egrep -v "killing process|dependencies couldn't be built" "$attr.fetchlog" | tail -n2 | sed "s~output path .* has .* hash ‘(.*)’ when .* was expected|fixed-output derivation produced path '.*' with .* hash '(.*)' instead of the expected hash '.*'~12~" | head -n1) </del> <ins> newHash=$(egrep -v "killing process|dependencies couldn't be built|wanted: " "$attr.fetchlog" | tail -n2 | sed "s~output path .* has .* hash ‘(.*)’ when .* was expected|fixed-output derivation produced path '.*' with .* hash '(.*)' instead of the expected hash '.*'|  got:    .*:(.*)~123~" | head -n1) </ins> fi if [ -z "$newHash" ]; then

Related discussion:
text: When used with latest Nix the "new" hash is extracted incorrectly, or thereabouts. This seems to be due to Nix changing the message used to be more friendly to humans: Use an update script invoking common-updater-scripts. Sorry, LMK if repro is needed. Please run and paste the results. I don't expect this to be helpful but happy to provide anyway! system: host os: multi-user?: sandbox: version: channels(will): channels(root): nixpkgs:
It is increasingly messy, perhaps we can drop the old regexes, most people probably set instead of changing nix in overlays so this would not be affected.
What about adding a flag to nix, which turns on machine readable error messages with a guaranty that those messages will not change in a backward incompatible way? Would need someone to add that. But wouldn't that be better to parse error messages intended for human readers with shell tools?
Alternatively, if the build fails, I think we could do something like:
I'm not sure I follow, but FWIW I ran into this and I set and don't set it via overlay. Looks like the new behavior is in 2.2, the current default for : (err formatting might not work for email responses, maybe? sorry :)) I think it's reasonable to drop support for nix older than what's in the tree-- especially since you'd have to overlay to replace it and as you say would likely do via anyway. Oh... that's probably what you meant! :D
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Any updates on this?
I marked this as stale due to inactivity. &rarr;
Should have been fixed by
Thanks!
Code change:
availableBinaries = { x86_64-linux = { platform = "linux-x64"; <del> checksum = "sha256-9o0nprGcJhudS1LNm+T7Vf0Dwd1RBauYKI+w1FBQ3ZM="; </del> <ins> checksum = "sha256-zS/yMXNNYlxgYyUDou2HaXuetPotqiOM8kv1Y7JouCo="; </ins> }; aarch64-linux = { platform = "linux-arm64"; <del> checksum = "sha256-aW3cUZqAdiOLzOC9BQM/bTkDVyw24Dx9nBSXgbiKe4c="; </del> <ins> checksum = "sha256-rB0ak6jYnJMb0aHDLAyhaGoOFK4FXDLEOeofNdW/Wk8="; </ins> }; }; inherit (stdenv.hostPlatform) system;

Related discussion:
text: Package name: cypress Latest released version: 13.13.2 <!-- Search your package here: --- Current version on the unstable channel: 13.2.0 Current version on the stable/release channel: 13.2.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! --- The following PR exists but seems to be abandoned: Weirdly enough I am also experiencing that the 13.2.0 version actually delivers 12.17.1, I don't know why...: ! 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]:
Code change:
systemd.services.display-manager = { description = "X11 Server"; <del> after = [ "acpid.service" "systemd-logind.service" ]; </del> <ins> after = [ "acpid.service" "systemd-logind.service" "systemd-user-sessions.service" ]; </ins> restartIfChanged = false;

Related discussion:
text: Describe the bug On a cold boot, exits uncleanly, leaving a black screen. This issue seems to have appeared on 20.03 (stable) up to the (at the time of this report) latest channel. Running from a different TTY will immediately load Plasma with the expected automatic login. To Reproduce Steps to reproduce the behavior: as an import at the top of the system configuration and set Expected behavior Automatic login to Plasma after the Plymouth screen. Screenshots No screenshots, but here's an excerpt of the output of : Additional context Using the same configuration this issue appears on only 2 of my 3 machines. The affected ones are using Intel integrated graphics with SSDs, while the other one has an older AMD GPU and HDD. I'm unsure if this could be an issue relating to drivers (with autologin off, SDDM and X work OOTB) or the significant difference in boot times. Notify maintainers Metadata Maintainer information:
I can reproduce this on a machine with AMD graphics; the issue seems to be a race condition with individual user login not being permitted before SDDM starts. Normally you don't notice because it's done by the time you finish typing in your password, but with autologin enabled it doesn't have to wait for the human. I have had luck with this configuration: Which may be overkill, but does appear to work.
That doesn't sound like overkill to me. As a user, I definitely want the network and user sessions available before I log in! :sweat_smile:
Well yes :P But I mean, it's possible that it only needs one of or , not both, or that, say, implies so there's no need to explicitly list the latter.
I doubt this part: and are independent, and we need the display manager to wait until the other services are started, so we probably do need both. I'm not sure about the second part, I need to investigate.
I marked this as stale due to inactivity. &rarr;
Shouldn't be marked as stale, there are still . Would it be wise to start a PR for the tweaks suggested by They seem to work on hardware and configurations affected by this.
I agree, this is not stale. I think the suggestion above is the appropriate solution.
Thanks a lot, the annoying workaround is no longer needed and time to desktop is fast again!
Code change:
# - Inputs used for Darwin , CoreBluetooth, ForceFeedback, IOKit, OpenGL, libpng, hidapi }: <del> let desktopItem = makeDesktopItem { name = "dolphin-emu-master"; exec = "dolphin-emu-master"; icon = "dolphin-emu"; comment = "A Wii/GameCube Emulator"; desktopName = "Dolphin Emulator (master)"; genericName = "Wii/GameCube Emulator"; categories = "Game;Emulator;"; startupNotify = "false"; }; in stdenv.mkDerivation rec { </del> <ins> stdenv.mkDerivation rec { </ins> pname = "dolphin-emu"; version = "5.0-15260";

Related discussion:
text: The derivation of creates a different .desktop file from the "official" one that has a different name. This is probably done in order to differentiate the two versions of in case someone installs both of them, but the problem is that while it creates a new one, it doesn't delete the "official" one. Also, the new .desktop file should also set , otherwise games don't launch in Wayland. (Though maybe it should be a wrapper instead) (And, unrelated, but why and not ?) The same also applies to PATH: there are both and (which is a link made by the derivation to in the folder). For consistency, there should be made a , otherwise if both dolphins are installed, one overwrites the other in PATH. Steps to reproduce the behavior: dolphinEmuMaster; an app launcher; are both the original "Dolphin Emulator" and the new "Dolphin Emulator (master)" that open the same app (the master one doesn't set `QTQPAPLATFORM=xcb). PATH there are both and (which is a link). There should only be the "Dolphin Emulator (master)" desktop file, and in PATH there should be only (and instead of ). <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Code change:
<del> { stdenv, fetchzip, cmake }: </del> <ins> { stdenv, fetchurl, fetchzip, cmake }: </ins> stdenv.mkDerivation rec { version = "0.9.8.5";

Related discussion:
text: On nixos-unstable libglvnd (I think) has been failing to build since about a week ago. Build log: Update to the latest nixos-unstable channel Run with nvidia in
Related?
Actually it looks like this PR fixes this issue. Though nix channel is not yet updated.
Confirmed. Adding the following override fixed it for me:
Code change:
<del> diff --git a/CMakeLists.txt b/CMakeLists.txt index 80a3bdcd6..380a1573a 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -61,7 +61,7 @@ option( "Link dependencies using CMake's find_package and do not use internal builds" ${SRB2_CONFIG_SYSTEM_LIBRARIES_DEFAULT} ) -option(SRB2_CONFIG_ENABLE_TESTS "Build the test suite" ON) +option(SRB2_CONFIG_ENABLE_TESTS "Build the test suite" OFF) # This option isn't recommended for distribution builds and probably won't work (yet). cmake_dependent_option( SRB2_CONFIG_SHARED_INTERNAL_LIBRARIES @@ -80,25 +80,6 @@ option(SRB2_CONFIG_ZDEBUG "Compile with ZDEBUG defined." OFF) option(SRB2_CONFIG_PROFILEMODE "Compile for profiling (GCC only)." OFF) set(SRB2_CONFIG_ASSET_DIRECTORY "" CACHE PATH "Path to directory that contains all asset files for the installer. If set, assets will be part of installation and cpack.") -if(SRB2_CONFIG_ENABLE_TESTS) -	# https://github.com/catchorg/Catch2 -	CPMAddPackage( -		NAME Catch2 -		VERSION 3.4.0 -		GITHUB_REPOSITORY catchorg/Catch2 -		OPTIONS -			"CATCH_INSTALL_DOCS OFF" -	) -	list(APPEND CMAKE_MODULE_PATH "${Catch2_SOURCE_DIR}/extras") -	include(CTest) -	include(Catch) -	add_executable(srb2tests) -	# To add tests, use target_sources to add individual test files to the target in subdirs. -	target_link_libraries(srb2tests PRIVATE Catch2::Catch2 Catch2::Catch2WithMain) -	target_compile_features(srb2tests PRIVATE c_std_11 cxx_std_17) -	catch_discover_tests(srb2tests) -endif() - # Enable CCache # (Set USE_CCACHE=ON to use, CCACHE_OPTIONS for options) if("${CMAKE_HOST_SYSTEM_NAME}" STREQUAL Windows) @@ -113,12 +94,6 @@ if("${CMAKE_HOST_SYSTEM_NAME}" STREQUAL Windows) message(WARNING "USE_CCACHE was set but ccache is not found (set CCACHE_TOOL_PATH)") endif() endif() -else() -	CPMAddPackage( -		NAME Ccache.cmake -		GITHUB_REPOSITORY TheLartians/Ccache.cmake -		VERSION 1.2 -	) endif() # Dependencies @@ -179,7 +154,7 @@ include(GitUtilities) if("${SRB2_SDL2_EXE_NAME}" STREQUAL "") # cause a reconfigure if the branch changes get_git_dir(SRB2_GIT_DIR) -	configure_file("${SRB2_GIT_DIR}/HEAD" HEAD COPYONLY) +	#configure_file("${SRB2_GIT_DIR}/HEAD" HEAD COPYONLY) git_current_branch(SRB2_GIT_REVISION) </del>

Related discussion:
text: use instead of pulling the windows zip from github releases
I can review if you want to PR this
upstream has said that they'd rather us use the github mirror that they're going to set up
the github mirror has been created
Sorry, I have to delete the github mirror, due to bandwidth limits. Please use
the "SRB22.2" branch and/or "SRB2release_2.2.13" tag
Getting 500 errors when trying to access
does this work for you?
The link works however the download buttons don't. PRs welcome if anyone can get it working, but wait for to be merged first to avoid merge conflicts.
i have had another look, and have found that it might be better to pull directly from branch
Thanks, was able to get it to work with :+1: