Package Details: pcsx2-git 2.3.240.r2.g23c495b939-1

Git Clone URL: https://aur.archlinux.org/pcsx2-git.git (read-only, click to copy)
Package Base: pcsx2-git
Description: PlayStation 2 emulator
Upstream URL: https://github.com/PCSX2/pcsx2
Licenses: GPL-3.0-or-later
Conflicts: pcsx2
Provides: pcsx2
Submitter: alucryd
Maintainer: weirdbeard (xiota)
Last Packager: weirdbeard
Votes: 131
Popularity: 0.35
First Submitted: 2014-03-26 14:17 (UTC)
Last Updated: 2025-03-25 20:47 (UTC)

Pinned Comments

weirdbeard commented on 2024-08-17 03:40 (UTC)

https://github.com/PCSX2/pcsx2/pull/11632

This package now enables Cmake Package mode proper. PCSX2 will here on, be installed in the package standard folders /usr/bin, /usr/share, /usr/lib. Following the XDG standard pcsx2's config files remain in .config/PCSX2

In order to ensure a proper and clean upgrade. Uninstall this package COMPLETELY and clear cache before reinstalling.

Latest Comments

« First ‹ Previous 1 .. 8 9 10 11 12 13 14 15 16 17 18 .. 70 Next › Last »

weirdbeard commented on 2024-06-05 04:03 (UTC)

To further clarify, one of the major issues I had, had was linking to glslang and spriv when building locally. Something the package version has no issue with and ended up in the ppa having to be manually patched

weirdbeard commented on 2024-06-05 03:58 (UTC)

Because when you try to in a friendly manner apply the patched shaderc directly to pcsx2 things get sideways in a lot of ways very quickly. You'll end up eventually modifying patches. It's something about manually building it together with PCSX2 in the AUR environment that caused a bunch of linker and other issues.

My earlier comment was meant to display the maintainer for the ubuntu PPA had similar issues and it went ... Interesting.

The other issue is, if there's anymore patched updates that cause similar issues. I feel it could be better mitigated by keeping it separate from the pcsx2 package. And, having a separate AUR package better serves, the main pcsx2 package and potentially any DuckStation packages should they end up having issues.

xmusjackson commented on 2024-06-05 02:55 (UTC) (edited on 2024-06-05 03:18 (UTC) by xmusjackson)

@xiota I must be missing something; What do upstream issues have to do with whether you package this modified library separately or build and include it with this package? Once the upstream issues are resolved, this PKGBUILD will have to be updated to reflect the use of upstream shaderc anyway. I'm not impatient, I've already done what I consider to be the correct course of action for this package, I just feel that the current approach doesn't make much sense.

Package was already updated to resolve that issue.

I don't see where, line 144 of the PKGBUILD: install -Dm644 -t "${pkgdir}"/opt/"${pkgname%-git}" "/usr/lib/shaderc-non-semantic-debug/libshaderc_shared.so.1" I realize shaderc-non-semantic-debug was moved to makedepends so that it could be uninstalled from the system when building is done (as long as the user doesn't opt to keep makedeps, as some might), but don't you see how this is the wrong approach? There should not be a package installed on the system so that a file can be copied from it before it's uninstalled.

Your modified PKGBUILD does the same.

It does, I realized later that in this instance it shouldn't cause a problem. I'm not sure why but originally pcsx2 was looking in /usr/lib for shaderc_shared.so.1 instead of /opt/pcsx2 but the problem resolved itself, though it doesn't hurt to be explicit in this case. This comment could be ignored if you wish, the other point is still relevant though. Edit: This was from a previous commit that was overwritten before I squashed them, if you're curous:

-DCMAKE_INSTALL_RPATH="/opt/pcsx2" -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON

Upstream patching of shaderc is causing problems for a few packages and their maintainers.

Please explain the relevance of this. I'm not trying to be dense, I simply don't understand why this means we have to create another package to install on the system. I'm not asking that we switch to upstream, and I'm not just complaining because there is a second package, I just don't see the logic in this separate package when it will only ever be used by pcsx2 and only temporarily at that (once the previously mentioned issued are ironed out it will be removed from this PKGBUILD I assume) and feel I should speak up.

rodrigo21 commented on 2024-06-05 02:49 (UTC)

I'm also can't run on Vulkan.

This error is on the log: Failed to find function shaderc_compilation_status_to_string

patlefort commented on 2024-06-05 01:44 (UTC)

I can't get vulkan to work on this package. The flatpak version works however. I also tested @xmusjackson's version but same issue.

xmusjackson commented on 2024-06-04 23:52 (UTC) (edited on 2024-06-05 00:00 (UTC) by xmusjackson)

I don't understand what that has to do with this issue. The patchset is maintained by the pcsx2 devs and located in the source, so what maintenance are you doing? If we follow the same process the devs use to build the appimage, this is what we get. This is the only library dependency this build uses that's not used as it (and not linked in).

Really my biggest issue is that I've never seen a package copy a whole library from another package during it's install script, in cases where something like this is necessary, the custom library is built with a unique name or is placed in a subdirectory inside /lib (as this package does currently). However, instead of building pcsx2 to look for the library there, the rpath is skipped by the build command and the library is copied out of the live system into another place in the live system.

I can't say I understand why you would solve this dependency this way, and I don't understand how your comment is relevant to the issue of separately packaging this unique custom library, but if you are truly insistent that they should be separate packages then you should at least modify the PKGBUILD for PCSX2 to build the binary with an rpath pointing to /usr/lib/shaderc_non_semantic_debug as copying a system library that's only used by one program and then leaving it on the system in two places completely defeats the purpose of creating a separate package.

weirdbeard commented on 2024-06-04 21:36 (UTC)

The reason I don't do that is because with the original patch came several issues that caused more and more patches to pile up

https://git.launchpad.net/~tellowkrinkle/pcsx2-github-mirror/commit/?id=7095850c1875a0183ffd273935a44aef81585f71

Eventually, it becomes a maintenance nightmare of patch after patch, especially if more patches are added in the future. (Note that there's maybe a patch or two listed in there irrelevant to this point.)

« First ‹ Previous 1 .. 8 9 10 11 12 13 14 15 16 17 18 .. 70 Next › Last »