Package Details: pythia 8.2.35-1

Git Clone URL: https://aur.archlinux.org/pythia.git (read-only)
Package Base: pythia
Description: High-energy physics events generator.
Upstream URL: http://home.thep.lu.se/Pythia/
Licenses: GPL
Provides: pythia, pythia8
Submitter: sfncmp1729
Maintainer: kgizdov
Last Packager: kgizdov
Votes: 5
Popularity: 0.243639
First Submitted: 2015-12-24 00:04
Last Updated: 2018-04-16 12:17

Dependencies (7)

Required by (10)

Sources (4)

Latest Comments

kgizdov commented on 2016-10-17 14:41

This works and is tested:
https://gist.github.com/kgizdov/c92a145bfa376c0bbcf7c3290965b8e8

Please test for yourself and see how it works. I've fixed the following:
- package include & lib folders must be specified manually or we end up linking to './' which is bad
- python correctly identifies paths on it's own and load the package correctly
- boost-libs is enough as dependency as it includes zlib

* Pro-tip: run 'namcap' on your PKGBUILD and package to make sure everything is fine

kgizdov commented on 2016-10-17 13:30

Actually, you cannot just install the pythia8.py file into site-packages as it is statically linked to the C++ binary and needs to be in the same folder. See this:

kgizdov@arch ~ python /usr/lib/python3.5/site-packages/pythia8.py
Traceback (most recent call last):
File "/usr/lib/python3.5/site-packages/pythia8.py", line 94, in swig_import_helper
fp, pathname, description = imp.find_module('_pythia8', [dirname(__file__)])
File "/usr/lib/python3.5/imp.py", line 296, in find_module
raise ImportError(_ERR_MSG.format(name), name=name)
ImportError: No module named '_pythia8'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/lib/python3.5/site-packages/pythia8.py", line 104, in <module>
_pythia8 = swig_import_helper()
File "/usr/lib/python3.5/site-packages/pythia8.py", line 96, in swig_import_helper
import _pythia8
ImportError: No module named '_pythia8'

We need to make sure _pythia8.so and __pycache__ are available in the correct folders. I will update the Gist of the PKGBUILD when I have something concrete.

JP-Ellis commented on 2016-10-15 03:24

I created the patch on the makefile originally because I did not see the `--enable-shared` option for ./configure (though I did look... obviously not well enough). I agree that the configuration option should definitely be preferred.

kgizdov commented on 2016-10-14 12:59

If you're putting the shared object in /usr/lib and the python library in (..)/site-packages you do not have to modify PYTHONPATH. The file pythia.sh is not needed anymore, unless you need to set the other PYTHIA variables. On top of that, since the shared object is already in an included path, you do not need the last line to update the ld-config. Please make sure to only modify system variables when needed. This was the original problem with the package, which I tried to solve by moving Pythia in its own folder, but since you are now using the system default paths, you have to remove the added modifications to the system paths.

Moreover, I do not understand why you are patching the Makefile, when it is being regenerated by ./configure every time. Even so the patch accomplished nothing - exchanging the static lib for the shared object. The static lib is only made if the correct flag is raised. I believe the previous problems people were having was because the Python and C++ binaries were placed in a polluted env and mistaken for each other by the linker. I do not see why this patch is necessary.

kgizdov commented on 2016-10-11 23:55

There is a serious bug with that package. It sets an incorrect python path for the system, which has a negative effect on other packages. I was able to correct for it like so https://gist.github.com/kgizdov/c92a145bfa376c0bbcf7c3290965b8e8

The problem comes from the fact that /usr/lib should never be part of PYTHONPATH as per Arch's Python Environment guidelines. My patched PKGBUILD also resolves some other linking issues by making sure pythia has its own shared object path and the ld linker is notified of it.

JP-Ellis commented on 2016-06-15 11:42

@sfncmp1729 Regarding the use of `-march` and `-mtune`, I added them briefly to my PKGBUILD, but have since removed them again. The reason being is that these should (probably) be set in each user's `/etc/makepkg.conf`, instead of being hard-coded into the PKGBUILD itself.

Bigben37 commented on 2016-06-14 07:32

@JP-Ellis
thanks for the updated PKDBUILD, linking against the shared pythia library works now!

JP-Ellis commented on 2016-06-14 02:54

Recently, ROOT changed their use of GLIBCXX_USE_CXX11_ABI, so I have updated the PKGBUILD so that they are compatible with each other.

https://gist.github.com/JP-Ellis/3ce0625586ed19dc4896d3bcfc2a20e5

JP-Ellis commented on 2016-05-31 08:20

In response to your thoughts:

1. `gcc` and `gcc-libs` are (or should) be in `base-devel`, but I prefer to be explicit than not have them since I think it is better to be overly specific than to assume they'll always be there.

2. `boost-libs` is not just a make dependency since I believe that it will keep using them after being built (I may be wrong... but I'm pretty sure). I was considering changing the PKGBUILD so that `boost-libs` was an optional dependency and make the PKGBUILD dynamically add the flags based on the existence of the appropriate header files (this can be extended for all the other dependencies actually).

3. You are indeed correct about `zlib`. The `./configure` script searches for `zlib.h` which is part of the `zlib` package (https://www.archlinux.org/packages/core/x86_64/zlib/) that's my bad.

4. The package really should not be adding svn or other version control files into the system, hence why I remove them.

5. Yes, since they are temporary build outputs and should not be packaged.

6. O3 enables some additional optimizations which can result is a fair bit more code. If enabled selectively and tested properly, it can be really beneficial; however, applying blindly to whole projects can sometimes result in slower code, or may introduce bugs where the programmer initially relied on undefined behaviours. That's why I generally don't use O3. As for `march` and `mtune` both being set to `native`, it should be all good to use though it means that generated binaries may not run on other computers (which won't be a big issue in this case).

7. The makeflags need not be specified explicitly. The makepkg loads $MAKEFLAGS into the environment and `make` automatically uses them.

8. You're welcome!


If need be (or if I need to procrastinate), I'll update the PKGBUILD to automatically look for the additional packages and then add the flags.

sfncmp1729 commented on 2016-05-31 07:48

Nice! Especially thanks for the patch. Here's my thoughts:

1. `gcc` and `gcc-libs` are in `base-devel` so according to the wiki they should not be reported as dependencies.
2. Is boost used elsewhere but in conjunction with LHA? In this case I think it could be omitted (by the way isn't `boost-libs` a make dependency?)
3. I think that the correct (make) dependency for gzip support is `zlib`.
4. I think that the "Removing version control" lines in `prepare()` can be removed safely.
5. Is it really necessary to manually remove the object files inside `build()` (line 58 of the PKGBUILD)?
6. I know that the `O2` level of optimization is considered the standard one for package building, but I think that in this case the `-O3 -march=native` flags can be safely included. One reason is that, for numerical software as Pythia, poor performance are considered an issue. Besides I believe that can be safely assumed that most of the time package on AUR are installed on the very same the machine they are built on. Users with specific needs can manually remove CPU specific optimizations. An alternative would be to pass to --cxx-common the CFLAGS in the makepkg.conf.
7. Missing $MAKEFLAGS in make!
8. Thanks for removing the silly `rsync` dependency! Now can be removed from the makedepends.

As soon as I've made some changes and tested your package I will upload the package. Thanks a lot!

All comments