Search Criteria
Package Details: pyinstaller 6.11.1-2
Package Actions
Git Clone URL: | https://aur.archlinux.org/pyinstaller.git (read-only, click to copy) |
---|---|
Package Base: | pyinstaller |
Description: | Bundles a Python application and all its dependencies into a single package |
Upstream URL: | https://www.pyinstaller.org |
Licenses: | LicenseRef-custom |
Submitter: | jackdroido |
Maintainer: | envolution |
Last Packager: | envolution |
Votes: | 50 |
Popularity: | 1.20 |
First Submitted: | 2012-06-13 22:56 (UTC) |
Last Updated: | 2024-11-10 22:55 (UTC) |
Dependencies (8)
- binutils
- pyinstaller-hooks-contribAUR (pyinstaller-hooks-contrib-gitAUR)
- python-altgraphAUR
- python-setuptools
- python-build (make)
- python-installer (python-installer-gitAUR) (make)
- python-wheel (make)
- python-argcomplete (optional) – tab completion for CLI tools
Required by (10)
- booru-downloader-git (make)
- cget (make)
- dunst-timer (make)
- ftconall-git (make)
- hascal-git (make)
- pyobd (make)
- python-pyxel (optional)
- revhubinterface (make)
- revhubinterface-git (make)
- tf2cdownloader-git (make)
Latest Comments
« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »
wznmickey commented on 2024-06-27 08:52 (UTC)
If you meet the problem with checksum, you can remove your local cache and then rebuild the package. I did this and solved this problem.
yochananmarqos commented on 2024-06-15 15:41 (UTC)
@fyoory: I've just corrected the checksum for the second time. It was correct each time until it wasn't. I don't know if upstream is doing something or there's an issue with GitHub.
Rude comments are not welcome here.
fyoory commented on 2024-06-15 15:13 (UTC)
When oh when will the maintainer get off their tail and fix the checksums? Its like the first thing you should check, if you have not got a clue.
ytret commented on 2024-06-10 11:30 (UTC) (edited on 2024-06-10 11:32 (UTC) by ytret)
The checksum is wrong again, the right one for pyinstaller-v6.8.0.tar.gz is 8e1d14eb185ff37793f32fe96f6881abb0952f4c0f27f8bf7237f542ae149554, not 28baf23b178e581ea3ca5002bd33c974a7044bd9d5ec0a4cc6464fee7d912eeb
By the way, big thanks for reducing the number of tests run
fangederos commented on 2024-05-19 07:33 (UTC) (edited on 2024-05-19 07:36 (UTC) by fangederos)
Sorry if this is inappropriate, but I was unable to download this package for the good part of an hour because no mirrors were working.
gir861 commented on 2024-04-18 06:00 (UTC) (edited on 2024-04-18 06:05 (UTC) by gir861)
Same here:
syyyr commented on 2024-04-17 08:20 (UTC)
It looks to me that the checksum for the source is wrong:
but the current checksum is: a37fa49f49232b27d87238e3c7b48b98e688d256c2667c2368d5366193d04775
yochananmarqos commented on 2024-03-27 14:59 (UTC)
Sorry guys, turns out I apparently screwed up merging the latest
makepkg.conf
pacnew.@chrisjbillington: Thanks, I've applied the diff.
chrisjbillington commented on 2024-03-27 02:17 (UTC)
The problem seems to be that as of pacman 6.1, released earlier this month, Arch's default
makepkg.conf
has-Wp,-D_FORTIFY_SOURCE=3
inCFLAGS
, and this conflicts with pyinstaller passing-D_FORTIFY_SOURCE=2
.To retain the stricter setting if it's set (which probably makes sense?), one might patch the pyinstaller bootloader build script:
fortify-source-fix.diff
:makepkg
succeeds for me after this change.Perhaps there is a more sensible way, but I think at least this identifies the problem. Not sure why some others aren't seeing this problem, as I would have expected the default makepkg.conf to be used in a clean chroot.
chrisjbillington commented on 2024-03-27 01:00 (UTC) (edited on 2024-03-27 01:01 (UTC) by chrisjbillington)
It's failing for me in a chroot as well.
I haven't built AUR packages in chroots before, so I may not be doing it right, but I'm seeing the same problem when I build as below (script at the bottom of this comment). I'm on Arch on an x86-64 system, is there anything from my system that propagates into a chroot like this? I do have custom stuff in LD_PRELOAD, but I'm running the below script with LD_PRELOAD unset (and PATH set conservatively) just in case:
LD_PRELOAD= PATH=/usr/local/bin:/usr/bin:/usr/local/sbin ./build.sh
I think maybe most of the "errors" are irrelevant, since they correspond to other lines that are output when you run makepkg that appear to indicate success:
I think it's might only the last one that is fatal:
libdl does exist:
Perhaps the error raised (
_FORTIFY_SOURCE" redefined
) when checking forlibdl
is causing that detection step to fail and be interpreted as libdl not being present?Anyway, here's how I'm building in a chroot, let me know if I'm doing anything wrong:
« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »