This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via 8f89e509d2f3d369cb5adb30dd85713ff1c5305c (commit) via f2442bc2e9d41a68b9965c272794600836c36b8b (commit) via 0a295f3f396b990e03ab8faec37566de85c99fec (commit) via 0e3a4bd1fbb740b6bfce2ceb3e6acdfe84a4d486 (commit) via facd9533b002194e58cc47672ce7e23d40968e96 (commit) via c0da1ba13a22f099936f60a0d2a752c9ab739ae0 (commit) from de6249ce221aae4062ea131d4f676f7e3d44af28 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 8f89e509d2f3d369cb5adb30dd85713ff1c5305c Author: morganamilo <morganamilo@gmail.com> Date: Sun Sep 8 22:45:29 2019 +0100 pacman: speed up deptest Try and find an exact match via pkgcache before iterating the entire localdb. Gives a noticeable speed up for exact matches e.g. `pacman -T zlib` Signed-off-by: Allan McRae <allan@archlinux.org> commit f2442bc2e9d41a68b9965c272794600836c36b8b Author: morganamilo <morganamilo@gmail.com> Date: Sun Sep 8 22:45:28 2019 +0100 libalpm: short circuit alpm_find_dbs_satisfier when a satisfying package is already installed, we always pick it instead of prompting the user. So we can return that package as soon as we find it, instead of waiting until we've iterated through all the databases. Signed-off-by: Allan McRae <allan@archlinux.org> commit 0a295f3f396b990e03ab8faec37566de85c99fec Author: morganamilo <morganamilo@gmail.com> Date: Sun Sep 8 22:45:26 2019 +0100 libalpm: fix incorrect documentation Signed-off-by: Allan McRae <allan@archlinux.org> commit 0e3a4bd1fbb740b6bfce2ceb3e6acdfe84a4d486 Author: Eli Schwartz <eschwartz@archlinux.org> Date: Wed Oct 2 03:20:13 2019 -0400 meson: work around broken pkg-config file with private requires In addition to the general issue of staticlibs linkage, linking a static lib to a library() does not seem to generate the needed Libs.private. Rework how we handle this entirely. Instead of relying on convenience libraries, we will *sigh* go extract a boatload of .o files again, then relink those to the installable libalpm, while mentioning our dependencies again. We still have our guaranteed static library for linking arbitrary programs with (e.g. vercmp), and we still only generate one identical copy of the .o files, but now we potentially `ar` it up twice, which isn't so bad. And linking still works, and pkg-config files also still work. One alternative would be to explicitly list our dependencies to pkgconfig.generate with requires_private, but since gpgme might be an elevated config-tool dependency, this can fail with: meson.build:341:10: ERROR: requires argument not a string, library with pkgconfig-generated file or pkgconfig-dependency object, got <GpgmeDependency gpgme: True> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org> commit facd9533b002194e58cc47672ce7e23d40968e96 Author: Eli Schwartz <eschwartz@archlinux.org> Date: Wed Sep 18 23:46:58 2019 -0400 meson: fix incorrect libalpm version LIB_VERSION is supposed to be something like 11.0.1, not simply reiterate the project version. As a result, we ended up with this: $ pacman -V [...] Pacman v5.1.0 - libalpm v5.1.0 [...] Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org> commit c0da1ba13a22f099936f60a0d2a752c9ab739ae0 Author: Eli Schwartz <eschwartz@archlinux.org> Date: Wed Sep 18 23:44:57 2019 -0400 meson: fix libcommon being publicly exposed as a static link dependency libcommon isn't even installed, so that means libalpm.a (if installed) is fatally broken as it misses objects. The problem is that meson doesn't handle this case correctly: https://github.com/mesonbuild/meson/issues/3934 https://github.com/mesonbuild/meson/issues/3937 https://github.com/mesonbuild/meson/pull/3939 Work around this by manually extracting libcommon's .o files into the list of objects used to create libalpm. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org> ----------------------------------------------------------------------- Summary of changes: lib/libalpm/deps.c | 27 ++++++++++++++------------- meson.build | 28 +++++++++++++--------------- src/pacman/deptest.c | 4 +++- 3 files changed, 30 insertions(+), 29 deletions(-) hooks/post-receive -- The official pacman repository