Re: [PATCH 2/3] util.c: extend --print-format with %b for builddate

Hi Jelle,

Thanks for the series - would love to see it land and purse expac from my systems :-P

On Sat, 26 Mar 2022 at 15:54, Jelle van der Waa jelle@vdwaa.nl wrote:

From: Jelle van der Waa jelle@vdwaa.nl

Signed-off-by: Jelle van der Waa jelle@archlinux.org

doc/pacman.8.asciidoc | 10 +++++----- src/pacman/util.c | 11 +++++++++++ 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/doc/pacman.8.asciidoc b/doc/pacman.8.asciidoc index 49e392cb..8a9294fc 100644 --- a/doc/pacman.8.asciidoc +++ b/doc/pacman.8.asciidoc @@ -235,11 +235,11 @@ Transaction Options (apply to '-S', '-R' and '-U')

*--print-format* <format>:: Specify a printf-like format to control the output of the '--print'

•   operation. The possible attributes are: "%a" for arch, "%d" for
  

•   description, "%e" for pkgbase, "%f" for filename, "%g" for base64
  

•   encoded PGP signature, "%h" for sha256sum, "%n" for pkgname, "%p" for
  

•   packager, "%v" for pkgver, "%l" for location, "%r" for repository, and
  

•   "%s" for size.
  

•   operation. The possible attributes are: "%a" for arch, "%b" for
  

•   builddate, "%d" for description, "%e" for pkgbase, "%f" for filename,
  

•   "%g" for base64 encoded PGP signature, "%h" for sha256sum, "%n" for
  

•   pkgname, "%p" for packager, "%v" for pkgver, "%l" for location, "%r"
  

•   for repository, and "%s" for size.
    Implies '\--print'.
  
  
  

diff --git a/src/pacman/util.c b/src/pacman/util.c index 3b92e678..519765f1 100644 --- a/src/pacman/util.c +++ b/src/pacman/util.c @@ -1163,6 +1163,17 @@ void print_packages(const alpm_list_t *packages) free(temp); temp = string; }

•           /* %b : build date */
  

•           if(strstr(temp, "%b")) {
  

•                   char bdatestr[50] = "";
  

•                   time_t bdate = (time_t)alpm_pkg_get_builddate(pkg);
  

•                   if(bdate) {
  

AFAICT alpm_pkg_get_builddate() returns -1 on error, so this seems off. In case it's zero, a message like "00:00 hours, Jan 1, 1970 UTC" seems appropriate doesn't it? Grepping around - various in-tree code paths opt for the same assumption. Don't know if it's worth fixing or staying consistent.

Either way, hope this helps o/ -Emil