polymc: init at 7.0-unstable-2025-11-15#461881
Conversation
|
It works just like if you use the flake. However, I've set it to draft to see if I can fix the mangohud problem before this gets merged. |
nixpkgs-ci
Bot
added
10.rebuild-linux: 1-10
Fixed it up so it works on NixOS. Upstream will require a change on |
nixpkgs-ci
Bot
added
the
9.needs: reviewer
hustlerone
force-pushed
the
polymc
branch
2 times, most recently
from
42df405 to
6bc7033
Compare
|
Not sure how I'd get around the fact that the Java paths have to be simulated |
|
I think I have a solution, I'll try to see if I can implement this with symlinkJoin |
It's a big pain in the ass i can't think of anything that works. Setting jdks on PATH causes collision. Basically I'm trying to do it so you don't have to constantly change the Java runtime location after each mass rebuild and GC run. Waste of 4 hours trying to get something while avoiding FHSEnv. Anyone with suggestions regarding this is welcome |
|
Cleaning up the mangohud fix and upstreaming the patch rn |
|
|
hustlerone
force-pushed
the
polymc
branch
2 times, most recently
from
e73ab3b to
23ed6a5
Compare
SuperSandro2000
added
the
9.needs: community feedback
We already had a discussion, and we were approved by the Nix Steering Committee: #365781 (comment) |
There was a problem hiding this comment.
Regarding the attached decision by the previous steering committee:
That said, upstream authors of packages are not automatically included in the Nix community just by virtue of their work being packaged in Nixpkgs
violations of our Code of Conduct by upstream authors who are not community members do not automatically restrict Nixpkgs maintainers' work.
I believe this is an unhelpful distinction to make. Those listed within meta.maintainers are not the sole individuals who maintain their particular packages. Nixpkgs maintainers are also by and large a collective volunteer community, we also don't have anyone with security auditing skills on payroll (or really anyone for that matter).
In my opinion, the previous SC didn't include the fact that nixpkgs maintainers are expected to interact/establish some sort of relationship with upstream as part of regular package maintenance. If upstream maintainers expose nixpkgs maintainers to unsafe situations that the nixpkgs maintainers did not agree to, then that is not acceptable. Additionally, I personally am against compartmentalizing community spaces as so, especially since the work of maintaining packages leans more social/investigative than purely technical.
Regarding PolyMC on other packaging merits:
I am against including PolyMC because it seems to me to duplicate the Prism launcher featureset with the change being to essentially break Microsoft's EULA on the Minecraft video game product.
However, you must not distribute anything we've made unless we specifically agree to it. By "distribute anything we've made" what we mean is:
- give copies of our game software or content to anyone else;
- make commercial use of anything we've made;
- try to make money from anything we've made; or
- let other people get access to anything we've made in a way that is unfair or unreasonable.
While the Microsoft EULA is not enforced verbatim on all projects, NixOS is a commercial product and nothing that PolyMC does seems to be the result of reverse-engineering (it downloads the game assets and organizes them into a runnable format, much like if you had authenticated with an account).
In the derivation builder:
You're paying to play on Mojang authenticated servers, singleplayer is free.
This is a false statement, nowhere does Microsoft give you the permission to download and run Minecraft without payment/license (in the form of a Microsoft account).
I am against including PolyMC in-tree, especially how prismlauncher has superseded polymc already.
nixpkgs-ci
Bot
removed
the
9.needs: reviewer
|
NixOS is not a commercial product and we have plenty of packages that allow people to break EULAs (think yt-dl, plenty of Spotify players) and I'm totally okay with that. Whether or not end users are breaking an EULA of some product is not really a concern for or against packaging something in nixpkgs IMO. This is a really weird take. What people do with the free and open source software they obtain through nixpkgs is their concern not ours. This is part of the fundamental freedoms of free software. |
PolyMC is not a duplicate of Prism Launcher, as Prism is a hard fork of PolyMC with removed features (FTB, Direct Curseforge Downloading). PolyMC also does not condone piracy and has the same psudo-DRM system in place as Prism, the only difference being a compile flag to toggle it for testing purposes. This is the same as using something like the Forge/Fabric modding sdks, which let users directly boot the game without owning it. It seems this nixpkg already keeps the DRM enabled, meaning it does not allowed users who download the package to use offline / alternative auth accounts without an account that owns the game.
I see nowhere where its mentioned that nixpkg maintainers have to be in some sort of relationship with upstream packages they make flakes for. We have never been in contact with or asked anyone to make a nixpkg for PolyMC, but are happy people are willing to help create and maintain one to help bring back PolyMC to nixpkgs.
I'm very confused on what this actually means
We were already told we were allowed to be added back into nixpkgs, and prismlauncher does not supersede polymc as polymc has different features compared to prismlauncher (Direct Curseforge downloading, Alternative auth) |
Expected, or obliged to? I don't see anyone having a relationship with Microsoft over a bunch of fonts. Having a positive relationship with upstream is desirable for many reasons, but saying that maintaining packages is more about socialising with strangers over actually making it work is flat out wrong. This mindset is a slippery slope and I've seen firsthand how a once productive community has degenerated into an unproductive circlejerk, with nothing good going for it. After all, people come here because of the work put into nixpkgs.
And there's also no clause preventing you from downloading a full copy of Minecraft. In fact, you can download it along with its dependencies and assets freely from the endpoint. If you look at https://www.minecraft.net/en-us/usage-guidelines you will see that you're forbidden to re-distribute. PolyMC isn't doing any of that. The situation will not change until Mojang removes offline play. Please do your research. |
Wow I should've just done this from the start. It's pointless to pontificate over air-bud rules when this tells the whole story. I'm not wasting any more time on this. Nixpkgs reputation is not going to be put into jeopardy because we want the software from a person who crashed his own project over a code of conduct (and is not sorry about it!). https://prismlauncher.org/wiki/overview/faq/
Getting your own project fractured over a piece of paper saying you can't insult minorities is, shocker, not something we should associate with! My changes requested is not a veto, but I'm done speaking about this and I think I have summarized the viewpoints contrary to this "fork" being included. |
If you believe we should not allow software into nixpkgs because of the reputation of said developers, we could start by removing hyprland and dwm, since we don't want to associate with neither vaxry or suckless. |
|
yes thank you minecraft now how the fuck can't you see |
| patches = [ | ||
| # APPLE branch hardcodes INSTALL_BUNDLE=full (bundles Qt via fixup_bundle, | ||
| # conflicting with nixpkgs' wrapped Qt); force nodeps. | ||
| ./mac.patch | ||
| ]; |
There was a problem hiding this comment.
What's the reason for this? The substitute was fine for this small of a change.
There was a problem hiding this comment.
There is another exact same line for Win32
There was a problem hiding this comment.
Begs the question, how should it work on win32? Surely a nix-built windows package should still use other nix packages for its libraries, just like on Linux and Darwin?
There was a problem hiding this comment.
ok fine i'll bring it like it was before
MattSturgeon
left a comment
MattSturgeon
left a comment
There was a problem hiding this comment.
Another minor thing I missed earlier.
Also, I'll try and test this out locally too. I have an AMD (CPU + GPU) and an Intel (integrated GPU) systems. Both NixOS.
i dunno i think something's up with LD because it can't find mangohud either |
|
I can reproduce the linking issue. The launcher runs fine, but attempting to actually run the game results in graphics drivers not being found. Same on both Intel & AMD. Was it working before and something has broken, or was launching the game never tested? |
It was working before, yes. I still can't narrow down what the hell changed |
|
Narrowed it down to symlinkJoin being broken again |
|
Yup, __structuredAttrs strikes again |
| "--set LD_LIBRARY_PATH ${addDriverRunpath.driverLink}/lib:${lib.makeLibraryPath runtimeLibs}:${mangohud}/lib/mangohud" | ||
| "--prefix PATH : ${lib.makeBinPath runtimeBins}" |
There was a problem hiding this comment.
With structuredAttrs, each argument must be a separate list element. You can't use spaces to separate arguments.
| "--set LD_LIBRARY_PATH ${addDriverRunpath.driverLink}/lib:${lib.makeLibraryPath runtimeLibs}:${mangohud}/lib/mangohud" | |
| "--prefix PATH : ${lib.makeBinPath runtimeBins}" | |
| "--set" "LD_LIBRARY_PATH" "${addDriverRunpath.driverLink}/lib:${lib.makeLibraryPath runtimeLibs}:${mangohud}/lib/mangohud" | |
| "--prefix" "PATH" ":" (lib.makeBinPath runtimeBins) |
(This is actually one of the main benefits of structuredAttrs)
Same for
- "--prefix POLYMC_JAVA_PATHS : ${lib.makeSearchPath "bin/java" jdks}"
+ "--prefix" "POLYMC_JAVA_PATHS" ":" (lib.makeSearchPath "bin/java" jdks)of course. And any other lists of cli arguments we pass in via derivation attrs.
There was a problem hiding this comment.
makeCWrapper craps itself when I do this, let me see if it's strictly just for POLYMC_JAVA_PATHS
There was a problem hiding this comment.
it still does not help, symlinkJoiin is stil broken
There was a problem hiding this comment.
symlinkJoiin is stil broken
qtWrapperArgs is handled by wrapQtAppsHook, not symlinkJoin itself.
Edit: looks like the problem is
There was a problem hiding this comment.
If I do all:
structuredAttrs is enabled
wrapping Qt applications in /nix/store/m5f01kd24qkmg75lyr9i70mn09hczks1-polymc/bin /nix/store/m5f01kd24qkmg75lyr9i70mn09hczks1-polymc/sbin /nix/store/m5f01kd24qkmg75lyr9i70mn09hczks1-polymc/libexec /nix/store/m5f01kd24qkmg75lyr9i70mn09hczks1-polymc/Applica>
wrapping /nix/store/m5f01kd24qkmg75lyr9i70mn09hczks1-polymc/bin/polymc -> /nix/store/qh9yssrybkglvvf7k250n9ryl1lx6lky-polymc-unwrapped-7.0-unstable-2026-03-04/bin/polymc
<stdin>: In function 'main':
<stdin>:61:6: error: #error makeCWrapper: Unknown argument /nix/store/ip1kxiyrb3zhv27fwlmqbixb9bfkpdx4-qtbase-6.11.0-only-plugins-qml/lib/qt-6/plugins
There was a problem hiding this comment.
Yup they're missing
There was a problem hiding this comment.
this is what we should be getting:
# ------------------------------------------------------------------------------------
# The C-code for this binary wrapper has been generated using the following command:
makeCWrapper '/nix/store/qh9yssrybkglvvf7k250n9ryl1lx6lky-polymc-unwrapped-7.0-unstable-2026-03-04/bin/polymc' \
--prefix 'POLYMC_JAVA_PATHS' ':' '/nix/store/xrhf3v9017v3irpili57j1jxnk4wc710-openjdk-25.0.4+1/bin/java:/nix/store/v3n6jl0sxn64g97c5kxzriwj4fv6qnjh-openjdk-21.0.12+2/bin/java:/nix/store/glifx04kfvxkcfbi953siw3lazpc5m51-openjdk-17.0.20+2/bin/java:/nix/store/4wgr7m4i32dksq8ks601c4znn4aa7jmk-openjdk-8u502-b01/bin/java' \
--set 'LD_LIBRARY_PATH' '/run/opengl-driver/lib:/nix/store/7gwd2kvkx1s369cwiv5z4x2xjxbppav6-libx11-1.8.13/lib:/nix/store/l1im0bii1ld332kcgg0gr72k6xla2dq1-libxext-1.3.7/lib:/nix/store/ljxnc3sy590a8rzf59rvclkxg8h71qdf-libxcursor-1.2.3/lib:/nix/store/0kx9jb9qcvh9kg9qi8kxwxymbvbpykdj-libxrandr-1.5.5/lib:/nix/store/0vsyi3ll34n145g0n8nc8d4s4fs1f3kq-libxxf86vm-1.1.7/lib:/nix/store/7fnjx0b7a7f80055i43v9pwbx25lwh0v-libpulseaudio-17.0/lib:/nix/store/dpi7sgi4dmnddwjwdi57d8x06sx49vkn-libglvnd-1.7.0/lib:/nix/store/qb5rf473aqg0505rq9ig39sl3hwnss4h-glfw-3.4/lib:/nix/store/psl06rbppwa0dfapjaljqlbfrw6np79x-openal-soft-1.24.3/lib:/nix/store/chqq8mpmpyfi9kgsngya71akv5xicn03-gcc-15.2.0-lib/lib:/nix/store/d6vnmfmcz5b299180issiaad4m96wh8k-vulkan-loader-1.4.341.0/lib:/nix/store/b89rbd2k8k3a8va6xkmh4nizgrpwv0y4-wayland-1.25.0/lib:/nix/store/05pzsrj4dmxlfwf8z70hp5vfgvfvfa54-systemd-minimal-libs-260.1/lib:/nix/store/mi8lmzjfkmcmiwhsir8z8v4fyihi1mwf-gamemode-1.8.2-lib/lib:/nix/store/hi6wx7z4z8v2c08wws4zz1g4dxpi6h9r-mangohud-0.8.3/lib/mangohud' \
--prefix 'PATH' ':' '/nix/store/79jyxa0vx6lb7v3xw5jnvvp0pd73nx3y-xrandr-1.5.4/bin:/nix/store/vrq7lw83z69diw23m0m7d6ld5kwfp9q8-mesa-demos-9.0.0/bin' \
--prefix 'QT_PLUGIN_PATH' ':' '/nix/store/ip1kxiyrb3zhv27fwlmqbixb9bfkpdx4-qtbase-6.11.0-only-plugins-qml/lib/qt-6/plugins' \
--prefix 'QT_PLUGIN_PATH' ':' '/nix/store/wzvm2pvf98a71v0scgfhmi01lqcxahfr-qtbase-6.11.0/lib/qt-6/plugins' \
--prefix 'QT_PLUGIN_PATH' ':' '/nix/store/6j374v0xv72xjzjlg52dgy9xzyrqxi9y-qtsvg-6.11.0/lib/qt-6/plugins' \
--prefix 'QT_PLUGIN_PATH' ':' '/nix/store/0x7jcnb8rls5v0jrl17ji5zj3w99wbp2-qtdeclarative-6.11.0/lib/qt-6/plugins' \
--prefix 'NIXPKGS_QT6_QML_IMPORT_PATH' ':' '/nix/store/0x7jcnb8rls5v0jrl17ji5zj3w99wbp2-qtdeclarative-6.11.0/lib/qt-6/qml' \
--prefix 'QT_PLUGIN_PATH' ':' '/nix/store/fqfzc017d1x0n34k5i01sbal4196zhk6-qtwayland-6.11.0/lib/qt-6/plugins' \
--prefix 'NIXPKGS_QT6_QML_IMPORT_PATH' ':' '/nix/store/fqfzc017d1x0n34k5i01sbal4196zhk6-qtwayland-6.11.0/lib/qt-6/qml'
# (Use `nix-shell -p makeBinaryWrapper` to get access to makeCWrapper in your shell)
# ------------------------------------------------------------------------------------
There was a problem hiding this comment.
If qt wrapper structuredAttrs support is the final blocker, I'm ok ignoring the nixpkgs-vet rule when merging this so long as we commit to enabling structuredAttrs once the qt wrapper hook is fixed.
I did see that some of the darwin-related threads haven't been addressed yet, though.
There was a problem hiding this comment.
Let me see if I've missed any
There was a problem hiding this comment.
If qt wrapper structuredAttrs support is the final blocker, I'm ok ignoring the nixpkgs-vet rule when merging this so long as we commit to enabling structuredAttrs once the qt wrapper hook is fixed.
You could use this workaround until #526277 makes it to master:
diff --git a/pkgs/by-name/po/polymc/package.nix b/pkgs/by-name/po/polymc/package.nix
index afe5fb956fea..e6d51d23c8b6 100644
--- a/pkgs/by-name/po/polymc/package.nix
+++ b/pkgs/by-name/po/polymc/package.nix
@@ -3,6 +3,8 @@
lib,
symlinkJoin,
addDriverRunpath,
+ makeSetupHook,
+ writeScript,
msaClientID ? null,
msaRequired ? true,
@@ -62,13 +64,28 @@ let
enableLTO
;
};
+
+ # Workaround for https://github.com/NixOS/nixpkgs/issues/526275
+ # Convert qtWrapperArgs to a string for wrapQtAppsHook
+ # (wrapQtAppsHook will convert it back into an array)
+ qtWrapperWorkaround = makeSetupHook { name = "wrap-qt-apps-workaround-hook"; } (
+ writeScript "wrap-qt-apps-workaround-hook.sh" ''
+ _qtWrapperArgs="''${qtWrapperArgs[*]}"
+ unset qtWrapperArgs
+ qtWrapperArgs="$_qtWrapperArgs"
+ unset _qtWrapperArgs
+ ''
+ );
in
symlinkJoin {
name = "polymc";
inherit (polymc) version;
paths = [ polymc ];
- nativeBuildInputs = [ kdePackages.wrapQtAppsHook ];
+ nativeBuildInputs = [
+ qtWrapperWorkaround
+ kdePackages.wrapQtAppsHook
+ ];
buildInputs = with kdePackages; [
qtbase
qtwayland
@@ -77,9 +94,7 @@ symlinkJoin {
postBuild = "wrapQtAppsHook";
strictDeps = true;
-
- # TODO: re-enable once wrapQtAppsHook is fixed
- __structuredAttrs = false;
+ __structuredAttrs = true;
qtWrapperArgs =
letHowever, one issue with the above workaround is there will be a period where the hook is fixed, but the workaround is still applied.
You could instead target staging, once #526277 is merged.
Apparently, staging should reach master in something like two to four weeks.
I did see that some of the darwin-related threads haven't been addressed yet, though.
E.g. https://github.com/NixOS/nixpkgs/pull/461881/changes#r3328990707
hustlerone
force-pushed
the
polymc
branch
2 times, most recently
from
363b345 to
9ed4aa8
Compare
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
|
qt wrap hook fix works EDIT(by @MattSturgeon): when the fix is applied; we still need to wait for staging -> master and then rebase this PR |
Co-authored-by: khaneliman <khaneliman12@gmail.com> Co-authored-by: Kaydax <kaydax@kaydax.xyz>
|
Got it to build with the patch, thanks for the work! Vanilla and stable mc launches, but gregtech modpack beta 2.9 (link to multimc zip) gives me: I'm not sure if it's just the modpack (it is a beta!) but given the similarity to the above, that I can't see anything with a cursory search of upstream issues, and prior occurrences of this kind of thing turning out to be nix related I thought I'd drop this here in case it recognizably is an issue with this package. |
Try overriding On my machine it's fine. |
You can run that exact beta fine? Strange, I can run everything else such as stable version fine:
Just not that. I did try and override, maybe incorrectly? Still fairly new to nix. I ended up resorting to use an llm to help me write this: as I had a very hard time getting it to build at all otherwise. I kept getting: |
Somehow you are missing the opengl driver libraries in the polymc environment. I don't use nix so I'm not sure how to fix it but this issue usually always happens when OpenGL isn't available... else if you are using wayland this does tend to happen randomly on newer lwjgl. You could also try the normal lwjgl 2 version of GTNH and see if that fixes the crash |
ugh, you're right, it seems to be a quirk of my setup of niri (wayland) /nvidia: GTNewHorizons/lwjgl3ify#317 discovered after going down a rabbit hole with __GL_THREADED_OPTIMIZATIONS=0 and trying to run in xwayland. but SDL_VIDEODRIVER=wayland did the job. |
12 participants
Adds PolyMC back into nixpkgs. Nix code is pretty much copypasted from upstream.
Feedback welcome.
Closes #365781
Supersedes #369915 (I assume orvitpng gave up)
Things done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.Add a 👍 reaction to pull requests you find important.