> On Sat, 14 Dec 2019, Michał Górny wrote:
> Actually, I added that because of your comment that people should be
> rebasing patches rather than removing context.
Isn't rebasing easier than removing context, anyway? I'd trust the
maintainer to do the right thing there.
The main argument is
On Fri, 2019-12-13 at 23:49 +0100, Ulrich Mueller wrote:
> > > > > > On Fri, 13 Dec 2019, Mike Gilbert wrote:
> > > > It also triggers pointless bug reports. Please remove this.
> > >
> > > I don't like that eqawarn either (see above).
> > >
> > > OTOH, users shouldn't normally have "qa" in
> On Fri, 13 Dec 2019, Mike Gilbert wrote:
>> > It also triggers pointless bug reports. Please remove this.
>>
>> I don't like that eqawarn either (see above).
>>
>> OTOH, users shouldn't normally have "qa" in PORTAGE_ELOG_CLASSES,
>> so they won't see the warning?
> Here's a bug report
On Thu, Dec 12, 2019 at 4:15 PM Ulrich Mueller wrote:
>
> > 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
> 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
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
> On Thu, 28 Nov 2019, Michał Górny wrote:
>> The difference is that there is now a QA warning for something that
>> is perfectly within the spec. Maybe the extra verboseness would be
>> enough, but the eqawarn line should be omitted? It doesn't provide
>> any info that isn't already present
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 something that is
> perfectly within the spec. Maybe the extra
> 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 something that is
perfectly within the spec. Maybe the extra verboseness would be enough,
but the eqawarn line should be omitted? It
On 11/27/19 2:17 PM, Michał Górny wrote:
>
> To achieve that, attempt to apply each patch with -F0 --dry-run first.
> If this succeeds, just silently apply the patch for real. If it
> doesn't, output an explicit eqawarn that the patch does not apply
> cleanly and retry with the default fuzz
On 11/27/19 11:17 AM, Michał Górny wrote:
> 12d0c48ad disabled silent output for eapply, in order to obtain fuzz
> factors in build logs. However, this also causes eapply to report all
> patched files which can make logs unreadable when there are no fuzz
> factors to be reported. Instead, use
12d0c48ad disabled silent output for eapply, in order to obtain fuzz
factors in build logs. However, this also causes eapply to report all
patched files which can make logs unreadable when there are no fuzz
factors to be reported. Instead, use verbose output only when applying
the patch with -F0
12 matches
Mail list logo
