Talk:Makepkg

optimized package options

Just to double check: the CFLAGS of /etc/makepkg.conf is overwritten by the CFLAGS that can be found in the Makefile provided with the source. This makes it ineffective as soon as a Makefile is provided, is it correct? Should it be mentioned in this case?

Kewl (talk) 10:38, 1 January 2018 (UTC)

Makefiles can just extend the environment's CFLAGS by not doing any explicit assignment, but using operators like ?= or += instead. See also [1]. -- Lahwaacz (talk) 12:11, 1 January 2018 (UTC)

Thanks that clarifies, do you think the wiki is clear enough or is it worth adding a comment about it or a link? Kewl (talk) 15:28, 1 January 2018 (UTC)

Well, the general note in the section is good enough for me, but feel free to add a comment... -- Lahwaacz (talk) 16:42, 1 January 2018 (UTC)

upx

A feature to be aware of: do not be surprised if the UPX option does not compress your gcc binary because it only detects files that are of mime type 'application/x-executable' | 'application/x-dosexec' while gcc unless instructed otherwise would create by default a binary 'application/x-sharedlib'. This is visible in /usr/share/makepkg/tidy/upx.sh Kewl (talk) 15:33, 1 January 2018 (UTC)

Indeed, but also note that upx will not be included in pacman in the future, which is why I am providing it with makepkg-optimize^AUR. I am willing to add other mimetypes to this list, provided we can establish that it is in fact safe to compress them with upx. I've found very little about the matter by searching, so we'll probably have to conduct our own tests.

Note, you could do such tests for yourself by appending | 'application/x-sharedlib', etc to the list in /usr/share/makepkg/tidy/upx.sh, before the ) at the end of the line. This seems relevant. quequotion (talk) 12:25, 16 February 2019 (UTC)

Proposal: Troubleshooting: ERROR: One or more PGP signatures could not be verified!

Comment: This ports over one of the FAQs from the AUR page. I do not feel it is appropriately placed there, as this error is not limited to AUR packages. This is more appropriately placed on the makepkg page. quequotion (talk) 15:18, 12 February 2019 (UTC)

Went ahead with this ahead of the larger AUR FAQ proposal, as uncontested here and indeed, this error can be thrown from any package with signatures if a user's keyring is incomplete or out-of-date. It belongs on the makepkg page. quequotion (talk) 06:40, 21 February 2019 (UTC)

Most likely you do not have the required public key(s) in you personal keyring to verify downloaded files. If one or more .sig files are downloaded while building the package, makepkg will automatically verify corresponding file(s) with the public key of its signer. If you do not have the required key in your personal keyring, makepkg will fail to do the verification.

The recommended way to deal with this problem is to import the required public key, either manually or from a key server. Often, you can simply find the fingerprint of the needed public key(s) in the validpgpkeys section of the PKGBUILD.