Package Base Details: python-p4python

Git Clone URL: (read-only, click to copy)
Submitter: WhittlesJr
Maintainer: adytzu2007
Last Packager: adytzu2007
Votes: 0
Popularity: 0.000000
First Submitted: 2017-05-05 18:59
Last Updated: 2019-11-05 22:53

Latest Comments

1 2 Next › Last »

adytzu2007 commented on 2019-11-05 22:54

Updated, thanks.

lostgoat commented on 2019-11-01 21:44

The p4api tarball has again updated to 2018.1.1852931

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