Package Details: python2-p4python 2018.2.1743033-2

Git Clone URL: (read-only)
Package Base: python-p4python
Description: Interface to Perforce API for Python 2
Upstream URL:
Licenses: custom
Submitter: WhittlesJr
Maintainer: adytzu2007
Last Packager: adytzu2007
Votes: 0
Popularity: 0.000000
First Submitted: 2017-05-05 18:59
Last Updated: 2019-09-13 19:26

Latest Comments

adytzu2007 commented on 2019-09-13 19:27

Updated, thanks for the heads up.

lostgoat commented on 2019-09-13 18:56


The current package fails to build because the p4api tarball has been updated with the following:

-            'e1c9e08b4db0b333510ae814e316e506c48f7eb80b654367bed003096ea8a5ec')
+            'caa06e47fde11c5918524a1248fa51c7a08e597b01fb0d62a8cf85d95b359bb5')

WhittlesJr commented on 2017-08-17 15:40

There are a number of suggestions in the forum thread now.

WhittlesJr commented on 2017-08-17 13:53

Well now I'm not so sure. Moving the conversation here:

WhittlesJr commented on 2017-08-17 13:38

I'm kinda with you on the counter-intuitiveness there. Others have complained about similar things, like taking twice as long to build large packages on slow systems (although surprisingly I have not seen anyone complain about python3/2).

With python-setuputils and python2-setuputils as makedepends for this and pyalsaaudio, AUR helpers will install python2 if it's not there already, and at least this way it's not a surprise if you're manually building.

But because I'm sympathetic, I'd say go ahead and submit a spinoff package like python2-p4python-python2only or something better-named. I think your use case is perhaps not typical but is still valid.

f0ff886f commented on 2017-08-17 13:12

So I'm not an expert on the normal way to do it in this case. python-pyalsaaudio would also fail building on my install, where I don't have python2, and choosing to always build python2 packages seems counter-intuitive when there is no interdependancy between 2 and 3.

Regarding the flags, openssl-1.0 should be a makedepends because the .so will link to if it doesn't find the 1.0 lib at link time.

Lastly, I reported this upstream so hopefully the ssl issue will go away one day:

WhittlesJr commented on 2017-08-16 21:56

Mmk, so I'm sticking with one package for now, because the split package method is the standard.

I added the appropriate makedepends, which should mitigate the issue maybe?

For reference, my PKGBUILD is based off of

WhittlesJr commented on 2017-08-16 21:34

Oh I think I see the issue... makepkg builds *both* packages no matter what. It's up to you to install either or both of course but the building is kind of out of our hands, huh... I wonder why the other PKGBUILDs all do it this way, given that restriction... I'm still looking into it. If I have to split the package, I will, but I don't wanna

WhittlesJr commented on 2017-08-16 21:06

1) Are you referring to the build() step, which builds both python2 and python3? I can see how that would cause problems... So I'll break that up. But I disagree that the python2 package should be submitted separately, as the majority of python-* PKGBUILDs are done this way.

2) Thanks for the tip. So I'll add openssl-1.0 as a dependency and include that build flag. Sound good?

f0ff886f commented on 2017-08-16 20:03

Thank you for the very fast update for the new version.

I'd like to raise two issues with this project:

1) This tries to install p4python for python2 as well as python3. It should only install for python3, and the python2-p4python package, separately submitted to the AUR would be for python2 (makepkg breaks on systems without python2 installed).

2) This package needs a fix on current Arch installs for SSL. P4Python doesn't work with openssl 1.1, which is the default install on Arch. openssl-1.0 has the required headers and libraries, but in order to use the proper SSL version, you must pass "--ssl /usr/lib/openssl-1.0" to the "python build" in the PKGCONFIG.