July 2022 - Pacman-dev - lists.archlinux.org

[PATCH] dload: Remove unused ABORT_SIGINT
by Chris Down 21 Jul '22

21 Jul '22

The last user of ABORT_SIGINT was removed in commit 84723cab5dfc ("Cleanup the old sequential download code"), and this isn't exported as part of the public API. Signed-off-by: Chris Down <chris(a)chrisdown.name> --- lib/libalpm/dload.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c index 7c27c3ea..4fa17b35 100644 --- a/lib/libalpm/dload.c +++ b/lib/libalpm/dload.c @@ -153,8 +153,7 @@ static char *get_fullpath(const char *path, const char *filename, } enum { - ABORT_SIGINT = 1, - ABORT_OVER_MAXFILESIZE + ABORT_OVER_MAXFILESIZE = 1, }; static int dload_interrupted; -- 2.35.1

2 1

Extend print-format with expac options
by Jelle van der Waa 21 Jul '22

21 Jul '22

This patch series extends --print-format with a subset of the expac options. More options to be added in further patch series.

3 8

[PATCH] Correctly handle failure in getting build or install dates
by Allan McRae 21 Jul '22

21 Jul '22

alpm_pkg_get_builddate() and alpm_pkg_get_installdate() both return -1 on error. Correctly handle the error condition in pacman. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- src/pacman/package.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/pacman/package.c b/src/pacman/package.c index f2b6fa19..4fcc11f2 100644 --- a/src/pacman/package.c +++ b/src/pacman/package.c @@ -210,11 +210,11 @@ void dump_pkg_full(alpm_pkg_t *pkg, int extra) /* set variables here, do all output below */ bdate = (time_t)alpm_pkg_get_builddate(pkg); - if(bdate) { + if(bdate != -1) { strftime(bdatestr, 50, "%c", localtime(&bdate)); } idate = (time_t)alpm_pkg_get_installdate(pkg); - if(idate) { + if(idate != -1) { strftime(idatestr, 50, "%c", localtime(&idate)); } -- 2.37.0

1 0

[RFC][WIP][PATCH 0/5] adding extended package data
by Andrew Gregory 21 Jul '22

21 Jul '22

ALPM is currently parsing several fields that are not particularly relevant to managing package installation (e.g. pkgbase, pkgtype, makedepends, checkdepends). pkgtype in particular is not even exposed in any way through the API, it has to be included in the parser with a "not actually used" comment. This patchset adds an extended data field to packages that can be used by packagers or package-building infrastructure to store arbitrary package data in a way that doesn't require altering alpm for every field and allows the data to actually be retrieved via alpm (though not as easily as first-class fields). Andrew Gregory (5): query: only strip leading local/ for db packages query: allow querying extra info for package files add data field for arbitrary package data query: print extended data when extra info is requested makepkg: store package type in extended data lib/libalpm/alpm.h | 7 +++++++ lib/libalpm/be_local.c | 25 +++++++++++++++++++++++++ lib/libalpm/be_package.c | 6 ++++++ lib/libalpm/be_sync.c | 16 ++++++++++++++++ lib/libalpm/package.c | 17 +++++++++++++++++ lib/libalpm/package.h | 6 ++++++ scripts/makepkg.sh.in | 2 +- src/pacman/package.c | 13 +++++++++++++ src/pacman/query.c | 16 ++++++---------- 9 files changed, 97 insertions(+), 11 deletions(-) -- 2.35.0

2 13

makedepends field of alpm_pkg_t
by Colin Woodbury 16 Jul '22

16 Jul '22

Hi guys, I have a brief question about the `makedepends` field of the `alpm_pkg_t` type. Try as I might, I'm unable to get this field to report anything (i.e. a non-empty alpm_list) for installed packages originally from the AUR that definitely had makedepends. This seems to be the case even when those makedepends are still installed. Under what circumstances should this field be expected to yield results? To be clear, I'm accessing it via the top-level `_pkg_get_makedepends` function. Thanks, Colin

2 2