Mess while trying to package PCSX2 at Launchpad
#1
Exclamation 
While trying to package PCSX2 for Ubuntu and Debian the relevant team got into a mess and stuck now. Perhaps PCSX2 developers could take a look.

https://bugs.launchpad.net/ubuntu/+bug/103791
Reply

Sponsored links

#2
Quote:PCSX2 0.9.6 Linux Binary
This is the PCSX2 0.9.6 emulator compressed package for linux.

While currently less stable then the Windows version, the Linux port is gradually catching up. So you may notice little things like Star Ocean not being playable, or occasional segfaults.

Dependencies:
gtk2, opengl, libbz2, libjpeg, glew-dev, libxxf86vm-dev, x11proto-xf86vidmodeautomake and autoconf (version >= 1.9) Nvidia Cg-Toolkit (link), libasound-dev, joystick

Download link 0.9.6

Quote:PCSX2 Linux Beta 1736 (6 September 2009)
Filling a gap that's been there for a while, here are binaries of the latest pcsx2 beta for Linux, based of revision 1736 of SVN.

As with the Windows betas, this is not supported. If you have issues, make sure you have all the dependencies installed, which last looked like this:
gtk2, opengl, libbz2, libjpeg, glew-dev, libxxf86vm-dev, x11proto-xf86vidmodeautomake and autoconf (version >= 1.9) Nvidia Cg-Toolkit, libasound-dev, and joystick

I'm compiling with Glew 1.5.1, and I've seen issues before if you use a different Glew version then the one I compiled against. I also downgraded my copy of libjpeg to version 6 before compiling, because most distributions are not using 7.

I've included a binary of ZZogl at r166[1], as well as OnePad, GSnull, and PadNull. The latter three are all considered alpha quality, and the former is by Zeydlitz.

[1] There is a newer release or two, but they were released after I talked with Zeydlitz about including it, so I decided to stick to the release we'd talked about.

Keep in mind we do not offer any kind of official support for this. It's mainly for users who want to try the latest additions. But you can report bugs in the bug reporting forum.

Download link beta: http://pcsx2.net/files/21118

They have their own, don't use the repo one.
Reply
#3
(05-27-2010, 06:33 PM)SkyBon Wrote: While trying to package PCSX2 for Ubuntu and Debian the relevant team got into a mess and stuck now. Perhaps PCSX2 developers could take a look.

https://bugs.launchpad.net/ubuntu/+bug/103791

One thing that should be working on your favor is that almost anything in the 3rdparty folders of the pcsx2 repositories are "MSW-only." Most of it simply doesn't need to be used or included into a unix distribution. So like there's reports bitching about the license status of zlib; yet the included zlib is typically an exact copy of that available with any standard linux package. It's there because there's no standard maintained set of common stable developer libs includes in MSW, nor available for easy download/install under MSW (which would typically include zlib, bz2, wxWidgets, pthreads, glut, etc. -- all of which would need to be downloaded and installed individually, and configured into MSVC by hand) .. and so Windows-oriented projects most commonly resort to including most of those things in the SVN, and also adding the fixed-location includes directly to the MSW project files; to help the devs retain their sanity.

Under Linux, most or all of 3rdparty/ is either unused (MSW-specific such as w32-pthreads), or can be removed entirely in favor of system-provided packages (zlib, bzip, wx, etc).

Once you exclude 3rdparty/ from the "license check", license issues should be nearly resolved (or possibly fully resolved, as I'm pretty sure there are no instances of hacked-in 3rdparty lib code in PCSX2 anymore).

One more important note: 0.9.7 will be MUCH more suited to a debian package. It's based on wxWidgets, and Arcum42 and I (finally!) fixed the main bugs causing random crashes in Linux (which were mostly related to GCC's automatic use of XMM registers and its mostly undocumented 16-byte aligned stack assumption). I really can't recommend any earlier versions of PCSX2 under Linux; it's a miracle any of them work at all, when you consider the potential for breakagesvia corrupted registers and bad stackframes (egad!).
Jake Stine (Air) - Programmer - PCSX2 Dev Team
Reply
#4
It's still using the 3rdparty folder copy of SoundTouch, but everything else is using the system libraries. And I can switch it to use the native copy of SoundTouch easily enough; I was just rather wary of differences between versions.
Reply
#5
(05-28-2010, 11:01 AM)arcum42 Wrote: It's still using the 3rdparty folder copy of SoundTouch, but everything else is using the system libraries. And I can switch it to use the native copy of SoundTouch easily enough; I was just rather wary of differences between versions.

Agreed. SoundTouch is typically unreliable about changes between versions breaking behavior in fairly significant ways. It should still be allowed as an option via cmake, though (just of the strongly not-recommended kind).

And technically the plugins aren't under the same license as PCSX2 proper; though most of the active ones are using GPLv3 now. We package them all together in a single SVN for sake of developer sanity (once again) -- but they're still considered as separate projects. They should all be GPLv2 or better though, and thus should be fully compatible.
Jake Stine (Air) - Programmer - PCSX2 Dev Team
Reply
#6
Yeah, I'll have to tweak it to make sure it's possible, since I quickly hardcoded it last weekend or so, when I was making sure the other libraries could easily use internal or external versions.

One of the reasons why I worry about the version is we're using version 1.5 of SoundTouch, and some distributions, such as Debian and Ubuntu, haven't updated since 1.3.1.

As far as the plugins go, the ones that are generally used in linux pretty much have their license all over the place. I see one or two of the Windows ones where it's hard to find[1], but those wouldn't need to be worried about for Linux anyways.

[1] Like cdvdGigaherz.
Reply
#7
Soundtouch package in debian is more or less orphaned so do not expect any upgrade in a near future. (and so ubuntu, surely based on debian). For information, I have a patch that remove post 1.3 feature on plugins to compile it with soundtouch 1.3. It is based on macro SOUNDTOUCH_VERSION_ID. It is clearly not ideal, but the only good solution is to upgrade the soundtouch debian package.

Note: Include statement must be fixed first before using my patch because in all case it will take 3rdparty include.
- #include "SoundTouch/SoundTouch.h"
+ #include "soundtouch/SoundTouch.h"

So it will need at least a rename of the directory and updates of some build systems.

The patch could also be kept debian/ubuntu specific. I let you judge it.

Edit: in last rev, include statement are already fix.
Reply




Users browsing this thread: 1 Guest(s)