On 7/8/20 9:14 PM, Filipe Laíns via arch-general wrote:

On Wed, 2020-07-08 at 21:08 +0200, NicoHood wrote:

...

Hey guys, i have recently received the attached email from a user. He cannot install a package from me due to a GPG error. I have recently updated my key and it should have been added to the new keyring. I don't know a better solution, who can help us?

Cheers, Nico

IIRC GPG uses the latest subkey by default, if you crated a new one it would be used, I assume this is what happened. If you haven't already revoked the older subkey(s), you should be able set GPGKEY in makepkg.conf and use it instead.

Cheers, Filipe Laíns

I am not sure if I understood correct. I've simply refreshed the gpg key (and the subkey) which was included into the new keyring. The package that causes trouble is older than that change. Since makepkg refers to package building, I think this does not help here. I expect that I do not need to rebuild all packages just because the GPG key was renewed. Is it more clear now?

On Friday, July 10, 2020 7:06 PM, Eli Schwartz via arch-dev-public <arch-dev-public@archlinux.org> wrote:

On 7/10/20 2:38 PM, Jan Alexander Steffens (heftig) via arch-dev-public wrote:

...

From: "Jan Alexander Steffens (heftig)" heftig@archlinux.org I recently read Fedora's documentation on build flags and I think they have some useful ideas.

1. Move -D_FORTIFY_SOURCE=2 from CPPFLAGS to CFLAGS using -Wp: Unfortunately, there are still build systems (e.g. CMake, homegrown Makefile rules) which use CFLAGS but not CPPFLAGS. Ultimately, we can cover more code with this workaround.

Sounds like a job for

build() { export CFLAGS="$CPPFLAGS $CFLAGS" ... }

(I do not understand how -Wp, helps here, its purpose is only to prevent the compiler driver from reinterpreting it before passing it to the preprocessor, and only if you have special needs and believe it will mangle your flags. -D_FORTIFY_SOURCE sounds sufficiently boring to say it won't be mangled.)

IIRC main concern against -D_FORTIFY_SOURCE in CFLAGS (made by Allan?) was about purity of passing preprocessor flags only to preprocessor. I think using "Wp" prefix for fortify solves purity issue. Side note: can you get rid of "-march=x86-64 -mtune=generic" which are default options for gcc on x86_64? It would be easier to read buildflags without this useless spam especially when they will be extended by other meaningful things. Yours sincerely G. K.