On 8/29/18 12:54 AM, Eli Schwartz wrote: > On 8/29/18 12:37 AM, Allan McRae wrote: >> On 14/08/18 11:25, Eli Schwartz wrote: >>> On 6/28/18 1:19 PM, Eli Schwartz wrote: >>>> This behavior is confusing, since it means absolutely everything goes to >>>> stderr and makepkg itself is a quiet program that produces no expected >>>> output??? >>>> >>>> The only situation where messages should go to stderr rather than >>>> stdout, is with --geninteg which is meant to return the checksums on >>>> stdout (but we don't want to totally get rid of status messages when >>>> redirecting the results elsewhere, or, worse, redirect status messages >>>> to a PKGBUILD). For this specific case, redirect message output to >>>> stderr in the --geninteg callers directly. >>>> >>>> Implements FS#17173 >>> Don't use this. >>> >>> Actually the pkgver() function saves the stdout of run_function_safe to >>> a variable, and this patch would ensure the variable contains some >>> decidedly not-pkgver content. :( >> >> Have not had time to look into this, but is there an easy/obvious way to >> adjust pkgver() capturing to stop this? Do we need to special case >> run_function? > > I was actually thinking, we should maybe special-case run_function to > not emit this when run in a subshell. > > Subshells aren't something we usually do, and when we do, it's probably > to capture output, as in fact it is here. > > So, we could then handle this surrounding the subshell, the same way I > did for https://patchwork.archlinux.org/patch/736/
Adding https://lists.archlinux.org/pipermail/pacman-dev/2018-August/022793.html on top of my branch with this patchset, makes pkgver() work again while sending messages to stdout. So this patchset is now back on the table. -- Eli Schwartz Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature