Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0

2019-12-12 Thread Ulrich Mueller
> On Thu, 12 Dec 2019, Mike Gilbert wrote: > On Wed, Nov 27, 2019 at 11:14 PM Michał Górny wrote: >> On Wed, 2019-11-27 at 23:49 +0100, Ulrich Mueller wrote: >> > The difference is that there is now a QA warning for something that >> > is perfectly within the spec. Maybe the extra

Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.

2019-12-12 Thread Michael Orlitzky
On 12/12/19 3:15 PM, Ulrich Mueller wrote: > > It was also suggested that we add -F0 in EAPI 8, but that would break > the build in those cases that are producing extra output now. I don't > think that would be preferable. It would only break the build for the maintainer, who would then

Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.

2019-12-12 Thread Ulrich Mueller
> On Thu, 12 Dec 2019, Mike Gilbert wrote: > I think this should be reverted. It causes too much noise, and > "solves" a problem only very rarely. Now, how many lines of output does this typically produce, compared to the total size of a typical build log? Especially with mgorny's subsequent

Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0

2019-12-12 Thread Mike Gilbert
On Wed, Nov 27, 2019 at 11:14 PM Michał Górny wrote: > > On Wed, 2019-11-27 at 23:49 +0100, Ulrich Mueller wrote: > > > > > > > On Wed, 27 Nov 2019, Michael Orlitzky wrote: > > > This now disagrees with the PMS algorithm, doesn't it? > > > > The difference is that there is now a QA warning for

Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.

2019-12-12 Thread Mike Gilbert
On Mon, Nov 25, 2019 at 11:53 AM Zac Medico wrote: > > On 11/25/19 5:03 AM, Ulrich Müller wrote: > > We generally try to have verbose build logs, e.g., by calling > > configure with --disable-silent-rules. Silencing patch contradicts > > this, and will suppress reporting of fuzz factors. > > > >

[gentoo-portage-dev] Build path abi missing in qemu-user

2019-12-12 Thread Joakim Tjernlund
When build in a qemu-user chroot I get odd build paths: /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-.ppc This path is missing the abi_ppc_32 like so: /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-abi_ppc_32.ppc I struggle to find out why this happens, any