[Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions

[Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions

[ci_notify]

[-- Attachment #1: Type: text/plain, Size: 2617 bytes --]

Dear contributor, our automatic CI has detected problems related to your patch(es).  Please find some details below.  If you have any questions, please follow up on linaro-toolchain@lists.linaro.org mailing list, Libera's #linaro-tcwg channel, or ping your favourite Linaro toolchain developer on the usual project channel.

In CI config tcwg_gcc_check/master-aarch64 after:

  | gcc patch https://patchwork.sourceware.org/patch/75674
  | Author: benjamin priour <vultkayn@gcc.gnu.org>
  | Date:   Mon Sep 11 19:44:34 2023 +0200
  | 
  |     analyzer: Move gcc.dg/analyzer tests to c-c++-common (3) [PR96395]
  |     
  |     Hi,
  |     
  |     Patch below is mostly done, just have to check the formatting.
  |     Althought, I'd like your feedback on how to manage named_constants
  |     from enum in C++.
  | ... 21 lines of the commit log omitted.
  | ... applied on top of baseline commit:
  | 048927ed856 i386: Handle CONST_WIDE_INT in output_pic_addr_const [PR111340]

FAIL: 68 regressions

regressions.sum:
		=== g++ tests ===

Running g++:g++.dg/analyzer/analyzer.exp ...
FAIL: c-c++-common/analyzer/call-summaries-2.c -std=c++14 (test for excess errors)
FAIL: c-c++-common/analyzer/call-summaries-2.c -std=c++17 (test for excess errors)
FAIL: c-c++-common/analyzer/call-summaries-2.c -std=c++20 (test for excess errors)
FAIL: c-c++-common/analyzer/call-summaries-2.c -std=c++98 (test for excess errors)
FAIL: c-c++-common/analyzer/memcpy-1.c -std=c++14  (test for warnings, line 25)
FAIL: c-c++-common/analyzer/memcpy-1.c -std=c++14  (test for warnings, line 48)
FAIL: c-c++-common/analyzer/memcpy-1.c -std=c++14 (test for excess errors)
... and 63 more entries

You can find the failure logs in *.log.1.xz files in
 - https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-precommit/2244/artifact/artifacts/artifacts.precommit/00-sumfiles/ .
The full lists of regressions and progressions are in
 - https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-precommit/2244/artifact/artifacts/artifacts.precommit/notify/ .
The list of [ignored] baseline and flaky failures are in
 - https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-precommit/2244/artifact/artifacts/artifacts.precommit/sumfiles/xfails.xfail .



-----------------8<--------------------------8<--------------------------8<--------------------------
The information below can be used to reproduce a debug environment:

Current build   : https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-precommit/2244/artifact/artifacts
Reference build : https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/927/artifact/artifacts

Re: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions

[Maxim Kuvyrkov]

Hi Everyone,

Normally, notifications from Linaro TCWG precommit CI are sent only to patch author and patch submitter.  In this case the sender was rewritten to "Benjamin Priour via Gcc-patches <gcc-patches@gcc.gnu.org>", which was detected by Patchwork [1] as patch submitter.

Hi Mark,

Is "From:" re-write on gcc-patches@ mailing list a side-effect of [2]?  I see that some, but not all messages to gcc-patches@ have their "From:" re-written.

Also, do you know if re-write of "From:" on gcc-patches@ is expected?

[1] https://patchwork.sourceware.org/project/gcc/list/
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=29713

Thanks!

--
Maxim Kuvyrkov
https://www.linaro.org

> On Sep 12, 2023, at 02:58, ci_notify@linaro.org wrote:
> 
> Dear contributor, our automatic CI has detected problems related to your patch(es).  Please find some details below.  If you have any questions, please follow up on linaro-toolchain@lists.linaro.org mailing list, Libera's #linaro-tcwg channel, or ping your favourite Linaro toolchain developer on the usual project channel.
> 
> In CI config tcwg_gcc_check/master-aarch64 after:
> 
>  | gcc patch https://patchwork.sourceware.org/patch/75674
>  | Author: benjamin priour <vultkayn@gcc.gnu.org>
>  | Date:   Mon Sep 11 19:44:34 2023 +0200
>  | 
>  |     analyzer: Move gcc.dg/analyzer tests to c-c++-common (3) [PR96395]
>  |     
>  |     Hi,
>  |     
>  |     Patch below is mostly done, just have to check the formatting.
>  |     Althought, I'd like your feedback on how to manage named_constants
>  |     from enum in C++.
>  | ... 21 lines of the commit log omitted.
>  | ... applied on top of baseline commit:
>  | 048927ed856 i386: Handle CONST_WIDE_INT in output_pic_addr_const [PR111340]
> 
> FAIL: 68 regressions
> 
> regressions.sum:
> === g++ tests ===
> 
> Running g++:g++.dg/analyzer/analyzer.exp ...
> FAIL: c-c++-common/analyzer/call-summaries-2.c -std=c++14 (test for excess errors)
> FAIL: c-c++-common/analyzer/call-summaries-2.c -std=c++17 (test for excess errors)
> FAIL: c-c++-common/analyzer/call-summaries-2.c -std=c++20 (test for excess errors)
> FAIL: c-c++-common/analyzer/call-summaries-2.c -std=c++98 (test for excess errors)
> FAIL: c-c++-common/analyzer/memcpy-1.c -std=c++14  (test for warnings, line 25)
> FAIL: c-c++-common/analyzer/memcpy-1.c -std=c++14  (test for warnings, line 48)
> FAIL: c-c++-common/analyzer/memcpy-1.c -std=c++14 (test for excess errors)
> ... and 63 more entries
> 
> You can find the failure logs in *.log.1.xz files in
> - https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-precommit/2244/artifact/artifacts/artifacts.precommit/00-sumfiles/ .
> The full lists of regressions and progressions are in
> - https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-precommit/2244/artifact/artifacts/artifacts.precommit/notify/ .
> The list of [ignored] baseline and flaky failures are in
> - https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-precommit/2244/artifact/artifacts/artifacts.precommit/sumfiles/xfails.xfail .
> 
> 
> 
> -----------------8<--------------------------8<--------------------------8<--------------------------
> The information below can be used to reproduce a debug environment:
> 
> Current build   : https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-precommit/2244/artifact/artifacts
> Reference build : https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/927/artifact/artifacts

gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Mark Wielaard]

Hi Maxim,

Adding Jeff to CC who is the official gcc-patches mailinglist admin.

On Tue, 2023-09-12 at 11:08 +0400, Maxim Kuvyrkov wrote:
> Normally, notifications from Linaro TCWG precommit CI are sent only to
> patch author and patch submitter.  In this case the sender was rewritten
> to "Benjamin Priour via Gcc-patches <gcc-patches@gcc.gnu.org>",
> which was detected by Patchwork [1] as patch submitter.

BTW. Really looking forward to your talk at Cauldron about this!

> Is "From:" re-write on gcc-patches@ mailing list a side-effect of [2]?
> I see that some, but not all messages to gcc-patches@ have their
> "From:" re-written.
> 
> Also, do you know if re-write of "From:" on gcc-patches@ is expected?

Yes, it is expected for emails that come from domains with a dmarc
policy. That is because the current settings of the gcc-patches
mailinglist might slightly alter the message or headers in a way that
invalidates the DKIM signature. Without From rewriting those messages
would be bounced by recipients that check the dmarc policy/dkim
signature.

As you noticed the glibc hackers have recently worked together with the
sourceware overseers to upgrade mailman and alter the postfix and the
libc-alpha mailinglist setting so it doesn't require From rewriting
anymore (the message and header aren't altered anymore to invalidate
the DKIM signatures).

We (Jeff or anyone else with mailman admin privs) could use the same
settings for gcc-patches. The settings that need to be set are in that
bug:

- subject_prefix (general): (empty)
- from_is_list (general): No
- anonymous_list (general): No
- first_strip_reply_to (general): No
- reply_goes_to_list (general): Poster
- reply_to_address (general): (empty)
- include_sender_header (general): No
- drop_cc (general): No
- msg_header (nondigest): (empty)
- msg_footer (nondigest): (empty)
- scrub_nondigest (nondigest): No
- dmarc_moderation_action (privacy): Accept
- filter_content (contentfilter): No

The only visible change (apart from no more From rewriting) is that
HTML multi-parts aren't scrubbed anymore (that would be a message
altering issue). The html part is still scrubbed from the
inbox.sourceware.org archive, so b4 works just fine. But I don't know
what patchwork.sourceware.org does with HTML attachements. Of course
people really shouldn't sent HTML attachments to gcc-patches, so maybe
this is no real problem.

Let me know if you want Jeff (or me or one of the other overseers) make
the above changes to the gcc-patches mailman settings.

Cheers,

Mark

> [1] https://patchwork.sourceware.org/project/gcc/list/
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=29713

Re: gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Iain Sandoe]

Hi Mark,

> On 12 Sep 2023, at 16:00, Mark Wielaard <mark@klomp.org> wrote:

> Adding Jeff to CC who is the official gcc-patches mailinglist admin.
> 
> On Tue, 2023-09-12 at 11:08 +0400, Maxim Kuvyrkov wrote:
>> Normally, notifications from Linaro TCWG precommit CI are sent only to
>> patch author and patch submitter.  In this case the sender was rewritten
>> to "Benjamin Priour via Gcc-patches <gcc-patches@gcc.gnu.org>",
>> which was detected by Patchwork [1] as patch submitter.
> 
> BTW. Really looking forward to your talk at Cauldron about this!
> 
>> Is "From:" re-write on gcc-patches@ mailing list a side-effect of [2]?
>> I see that some, but not all messages to gcc-patches@ have their
>> "From:" re-written.
>> 
>> Also, do you know if re-write of "From:" on gcc-patches@ is expected?
> 
> Yes, it is expected for emails that come from domains with a dmarc
> policy. That is because the current settings of the gcc-patches
> mailinglist might slightly alter the message or headers in a way that
> invalidates the DKIM signature. Without From rewriting those messages
> would be bounced by recipients that check the dmarc policy/dkim
> signature.
> 
> As you noticed the glibc hackers have recently worked together with the
> sourceware overseers to upgrade mailman and alter the postfix and the
> libc-alpha mailinglist setting so it doesn't require From rewriting
> anymore (the message and header aren't altered anymore to invalidate
> the DKIM signatures).
> 
> We (Jeff or anyone else with mailman admin privs) could use the same
> settings for gcc-patches. The settings that need to be set are in that
> bug:
> 
> - subject_prefix (general): (empty)
> - from_is_list (general): No
> - anonymous_list (general): No
> - first_strip_reply_to (general): No
> - reply_goes_to_list (general): Poster
> - reply_to_address (general): (empty)
> - include_sender_header (general): No
> - drop_cc (general): No
> - msg_header (nondigest): (empty)
> - msg_footer (nondigest): (empty)
> - scrub_nondigest (nondigest): No
> - dmarc_moderation_action (privacy): Accept
> - filter_content (contentfilter): No
> 
> The only visible change (apart from no more From rewriting) is that
> HTML multi-parts aren't scrubbed anymore (that would be a message
> altering issue). The html part is still scrubbed from the
> inbox.sourceware.org archive, so b4 works just fine. But I don't know
> what patchwork.sourceware.org does with HTML attachements. Of course
> people really shouldn't sent HTML attachments to gcc-patches, so maybe
> this is no real problem.
> 
> Let me know if you want Jeff (or me or one of the other overseers) make
> the above changes to the gcc-patches mailman settings.

yes, please!
Iain

> 
> Cheers,
> 
> Mark
> 
>> [1] https://patchwork.sourceware.org/project/gcc/list/
>> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=29713
> 

Re: gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Thomas Schwinge]

Hi Mark!

On 2023-09-13T17:02:05+0100, Iain Sandoe <idsandoe@googlemail.com> wrote:
>> On 12 Sep 2023, at 16:00, Mark Wielaard <mark@klomp.org> wrote:
>> Adding Jeff to CC who is the official gcc-patches mailinglist admin.
>>
>> On Tue, 2023-09-12 at 11:08 +0400, Maxim Kuvyrkov wrote:
>>> Normally, notifications from Linaro TCWG precommit CI are sent only to
>>> patch author and patch submitter.  In this case the sender was rewritten
>>> to "Benjamin Priour via Gcc-patches <gcc-patches@gcc.gnu.org>",
>>> which was detected by Patchwork [1] as patch submitter.
>>
>> BTW. Really looking forward to your talk at Cauldron about this!

(Yes!)

>>> Is "From:" re-write on gcc-patches@ mailing list a side-effect of [2]?
>>> I see that some, but not all messages to gcc-patches@ have their
>>> "From:" re-written.
>>>
>>> Also, do you know if re-write of "From:" on gcc-patches@ is expected?
>>
>> Yes, it is expected for emails that come from domains with a dmarc
>> policy. That is because the current settings of the gcc-patches
>> mailinglist might slightly alter the message or headers in a way that
>> invalidates the DKIM signature. Without From rewriting those messages
>> would be bounced by recipients that check the dmarc policy/dkim
>> signature.
>>
>> As you noticed the glibc hackers have recently worked together with the
>> sourceware overseers to upgrade mailman and alter the postfix and the
>> libc-alpha mailinglist setting so it doesn't require From rewriting
>> anymore (the message and header aren't altered anymore to invalidate
>> the DKIM signatures).
>>
>> We (Jeff or anyone else with mailman admin privs) could use the same
>> settings for gcc-patches. The settings that need to be set are in that
>> bug:
>>
>> - subject_prefix (general): (empty)
>> - from_is_list (general): No
>> - anonymous_list (general): No
>> - first_strip_reply_to (general): No
>> - reply_goes_to_list (general): Poster
>> - reply_to_address (general): (empty)
>> - include_sender_header (general): No
>> - drop_cc (general): No
>> - msg_header (nondigest): (empty)
>> - msg_footer (nondigest): (empty)
>> - scrub_nondigest (nondigest): No
>> - dmarc_moderation_action (privacy): Accept
>> - filter_content (contentfilter): No
>>
>> The only visible change (apart from no more From rewriting) is that
>> HTML multi-parts aren't scrubbed anymore (that would be a message
>> altering issue). The html part is still scrubbed from the
>> inbox.sourceware.org archive, so b4 works just fine. But I don't know
>> what patchwork.sourceware.org does with HTML attachements. Of course
>> people really shouldn't sent HTML attachments to gcc-patches, so maybe
>> this is no real problem.
>>
>> Let me know if you want Jeff (or me or one of the other overseers) make
>> the above changes to the gcc-patches mailman settings.
>
> yes, please!

Yes, please!  For all mailing lists, globally.


Grüße
 Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Re: gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Richard Biener]

On Tue, Sep 12, 2023 at 5:00 PM Mark Wielaard <mark@klomp.org> wrote:
>
> Hi Maxim,
>
> Adding Jeff to CC who is the official gcc-patches mailinglist admin.
>
> On Tue, 2023-09-12 at 11:08 +0400, Maxim Kuvyrkov wrote:
> > Normally, notifications from Linaro TCWG precommit CI are sent only to
> > patch author and patch submitter.  In this case the sender was rewritten
> > to "Benjamin Priour via Gcc-patches <gcc-patches@gcc.gnu.org>",
> > which was detected by Patchwork [1] as patch submitter.
>
> BTW. Really looking forward to your talk at Cauldron about this!
>
> > Is "From:" re-write on gcc-patches@ mailing list a side-effect of [2]?
> > I see that some, but not all messages to gcc-patches@ have their
> > "From:" re-written.
> >
> > Also, do you know if re-write of "From:" on gcc-patches@ is expected?
>
> Yes, it is expected for emails that come from domains with a dmarc
> policy. That is because the current settings of the gcc-patches
> mailinglist might slightly alter the message or headers in a way that
> invalidates the DKIM signature. Without From rewriting those messages
> would be bounced by recipients that check the dmarc policy/dkim
> signature.
>
> As you noticed the glibc hackers have recently worked together with the
> sourceware overseers to upgrade mailman and alter the postfix and the
> libc-alpha mailinglist setting so it doesn't require From rewriting
> anymore (the message and header aren't altered anymore to invalidate
> the DKIM signatures).
>
> We (Jeff or anyone else with mailman admin privs) could use the same
> settings for gcc-patches. The settings that need to be set are in that
> bug:
>
> - subject_prefix (general): (empty)
> - from_is_list (general): No
> - anonymous_list (general): No
> - first_strip_reply_to (general): No
> - reply_goes_to_list (general): Poster
> - reply_to_address (general): (empty)
> - include_sender_header (general): No
> - drop_cc (general): No
> - msg_header (nondigest): (empty)
> - msg_footer (nondigest): (empty)
> - scrub_nondigest (nondigest): No
> - dmarc_moderation_action (privacy): Accept
> - filter_content (contentfilter): No
>
> The only visible change (apart from no more From rewriting) is that
> HTML multi-parts aren't scrubbed anymore (that would be a message
> altering issue). The html part is still scrubbed from the
> inbox.sourceware.org archive, so b4 works just fine. But I don't know
> what patchwork.sourceware.org does with HTML attachements. Of course
> people really shouldn't sent HTML attachments to gcc-patches, so maybe
> this is no real problem.

Ick (to the HTML part).  I wonder if we can use From rewriting for those,
still stripping the HTML part?  Maybe we can also go back to rejecting
mails that are not text/plain ...

> Let me know if you want Jeff (or me or one of the other overseers) make
> the above changes to the gcc-patches mailman settings.
>
> Cheers,
>
> Mark
>
> > [1] https://patchwork.sourceware.org/project/gcc/list/
> > [2] https://sourceware.org/bugzilla/show_bug.cgi?id=29713
>

Re: gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Mark Wielaard]

Hi Thomas,

On Thu, Sep 14, 2023 at 09:00:39AM +0200, Thomas Schwinge wrote:
> >> Let me know if you want Jeff (or me or one of the other overseers) make
> >> the above changes to the gcc-patches mailman settings.
> >
> > yes, please!
> 
> Yes, please!  For all mailing lists, globally.

Call me a little conservative, but lets do this in stages. Although I
believe this works as intended, it is email and email is finicky.
Lets try out gcc-patches first. Then if that works and nobody
complains in say two week switch over other lists that receive patches
(gcc-rust, libstdc++, fortran and jit). But maybe just keep the
discussion lists as is for now.

Cheers,

Mark

Re: gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Mark Wielaard]

Hi Richard,

On Thu, Sep 14, 2023 at 11:07:21AM +0200, Richard Biener wrote:
> On Tue, Sep 12, 2023 at 5:00 PM Mark Wielaard <mark@klomp.org> wrote:
> > The only visible change (apart from no more From rewriting) is that
> > HTML multi-parts aren't scrubbed anymore (that would be a message
> > altering issue). The html part is still scrubbed from the
> > inbox.sourceware.org archive, so b4 works just fine. But I don't know
> > what patchwork.sourceware.org does with HTML attachements. Of course
> > people really shouldn't sent HTML attachments to gcc-patches, so maybe
> > this is no real problem.
> 
> Ick (to the HTML part).  I wonder if we can use From rewriting for those,
> still stripping the HTML part?

It is possible to mark some domains, like gmail.com which is used by a
lot of HTML posters, to always use From rewriting. But it isn't easy
to do it for emails containing HTML parts (and strip them).

>  Maybe we can also go back to rejecting
> mails that are not text/plain ...

Sadly people do seem to use these web email providers like gmail a
lot. Although not many people sent patches as email, reviews of those
patches do sometimes contain HTML parts.

Sorry,

Mark

Re: gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Mark Wielaard]

Hi all,

On Tue, Sep 12, 2023 at 05:00:07PM +0200, Mark Wielaard wrote:
> Adding Jeff to CC who is the official gcc-patches mailinglist admin.
> [...] 
> Yes, it is expected for emails that come from domains with a dmarc
> policy. That is because the current settings of the gcc-patches
> mailinglist might slightly alter the message or headers in a way that
> invalidates the DKIM signature. Without From rewriting those messages
> would be bounced by recipients that check the dmarc policy/dkim
> signature.
> 
> As you noticed the glibc hackers have recently worked together with the
> sourceware overseers to upgrade mailman and alter the postfix and the
> libc-alpha mailinglist setting so it doesn't require From rewriting
> anymore (the message and header aren't altered anymore to invalidate
> the DKIM signatures).
> 
> We (Jeff or anyone else with mailman admin privs) could use the same
> settings for gcc-patches. The settings that need to be set are in that
> bug:
> 
> - subject_prefix (general): (empty)
> - from_is_list (general): No
> - anonymous_list (general): No
> - first_strip_reply_to (general): No
> - reply_goes_to_list (general): Poster
> - reply_to_address (general): (empty)
> - include_sender_header (general): No
> - drop_cc (general): No
> - msg_header (nondigest): (empty)
> - msg_footer (nondigest): (empty)
> - scrub_nondigest (nondigest): No
> - dmarc_moderation_action (privacy): Accept
> - filter_content (contentfilter): No
> 
> The only visible change (apart from no more From rewriting) is that
> HTML multi-parts aren't scrubbed anymore (that would be a message
> altering issue). The html part is still scrubbed from the
> inbox.sourceware.org archive, so b4 works just fine. But I don't know
> what patchwork.sourceware.org does with HTML attachements. Of course
> people really shouldn't sent HTML attachments to gcc-patches, so maybe
> this is no real problem.

Although there were some positive responses (on list and on irc) it is
sometimes hard to know if there really is consensus for these kind of
infrastructure tweaks. But I believe there is at least no sustained
opposition to changing the gcc-patches mailman setting as proposed
above.

So unless someone objects I like to make this change Tuesday September
19 around 08:00 UTC.

And if there are no complaints at Cauldron we could do the same for
the other patch lists the week after.

Cheers,

Mark

> > [1] https://patchwork.sourceware.org/project/gcc/list/
> > [2] https://sourceware.org/bugzilla/show_bug.cgi?id=29713

Re: gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Mark Wielaard]

Hi all,

On Sun, Sep 17, 2023 at 10:04:37PM +0200, Mark Wielaard wrote:
> > We (Jeff or anyone else with mailman admin privs) could use the same
> > settings for gcc-patches. The settings that need to be set are in that
> > bug:
> > 
> > - subject_prefix (general): (empty)
> > - from_is_list (general): No
> > - anonymous_list (general): No
> > - first_strip_reply_to (general): No
> > - reply_goes_to_list (general): Poster
> > - reply_to_address (general): (empty)
> > - include_sender_header (general): No
> > - drop_cc (general): No
> > - msg_header (nondigest): (empty)
> > - msg_footer (nondigest): (empty)
> > - scrub_nondigest (nondigest): No
> > - dmarc_moderation_action (privacy): Accept
> > - filter_content (contentfilter): No
> > 
> > The only visible change (apart from no more From rewriting) is that
> > HTML multi-parts aren't scrubbed anymore (that would be a message
> > altering issue). The html part is still scrubbed from the
> > inbox.sourceware.org archive, so b4 works just fine. But I don't know
> > what patchwork.sourceware.org does with HTML attachements. Of course
> > people really shouldn't sent HTML attachments to gcc-patches, so maybe
> > this is no real problem.
> 
> Although there were some positive responses (on list and on irc) it is
> sometimes hard to know if there really is consensus for these kind of
> infrastructure tweaks. But I believe there is at least no sustained
> opposition to changing the gcc-patches mailman setting as proposed
> above.
> 
> So unless someone objects I like to make this change Tuesday September
> 19 around 08:00 UTC.

This change is now done for gcc-patches.

> And if there are no complaints at Cauldron we could do the same for
> the other patch lists the week after.
> 
> > > [1] https://patchwork.sourceware.org/project/gcc/list/
> > > [2] https://sourceware.org/bugzilla/show_bug.cgi?id=29713

Re: gcc-patches From rewriting mailman settings

[Mark Wielaard]

Hi,

On Sun, Sep 17, 2023 at 10:04:37PM +0200, Mark Wielaard wrote:
> On Tue, Sep 12, 2023 at 05:00:07PM +0200, Mark Wielaard wrote:
> > We (Jeff or anyone else with mailman admin privs) could use the same
> > settings for gcc-patches. The settings that need to be set are in that
> > bug:
> > 
> > - subject_prefix (general): (empty)
> > - from_is_list (general): No
> > - anonymous_list (general): No
> > - first_strip_reply_to (general): No
> > - reply_goes_to_list (general): Poster
> > - reply_to_address (general): (empty)
> > - include_sender_header (general): No
> > - drop_cc (general): No
> > - msg_header (nondigest): (empty)
> > - msg_footer (nondigest): (empty)
> > - scrub_nondigest (nondigest): No
> > - dmarc_moderation_action (privacy): Accept
> > - filter_content (contentfilter): No
> > 
> > The only visible change (apart from no more From rewriting) is that
> > HTML multi-parts aren't scrubbed anymore (that would be a message
> > altering issue). The html part is still scrubbed from the
> > inbox.sourceware.org archive, so b4 works just fine. But I don't know
> > what patchwork.sourceware.org does with HTML attachements. Of course
> > people really shouldn't sent HTML attachments to gcc-patches, so maybe
> > this is no real problem.
> 
> Although there were some positive responses (on list and on irc) it is
> sometimes hard to know if there really is consensus for these kind of
> infrastructure tweaks. But I believe there is at least no sustained
> opposition to changing the gcc-patches mailman setting as proposed
> above.
> 
> So unless someone objects I like to make this change Tuesday September
> 19 around 08:00 UTC.
> 
> And if there are no complaints at Cauldron we could do the same for
> the other patch lists the week after.

Since there were no complaints (and some happy users) and we didn't
real issues (there was an issue when using the Errors-To header, which
might break your dkim signature, but the only user of Errors-To has
dropped it) the jit, libstdc++, fortran and gcc-rust lists now also
have the above mailman settings.

The admin email address for fortran was updated to Toon's new address
and the one for libstdc++ was changed from bkoz to jwakely.

If there are any issues with the list settings please discuss on the
overseers@sourceware.org mailinglist.

Cheers,

Mark

> > > [1] https://patchwork.sourceware.org/project/gcc/list/
> > > [2] https://sourceware.org/bugzilla/show_bug.cgi?id=29713

Re: gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Gerald Pfeifer]

On Tue, 19 Sep 2023, Mark Wielaard wrote:
>> Although there were some positive responses (on list and on irc) it is
>> sometimes hard to know if there really is consensus for these kind of
>> infrastructure tweaks. But I believe there is at least no sustained
>> opposition to changing the gcc-patches mailman setting as proposed
>> above.
> This change is now done for gcc-patches.

Yeah, yeah, yeah. Thank you!

>> And if there are no complaints at Cauldron we could do the same for
>> the other patch lists the week after.

Sadly I missed Cauldron - have there been any complaints there?

Can you adjust the gcc@gcc.gnu.org list and others @gcc.gnu.org as well?
I for one would love to see that.

Thanks,
Gerald

Re: gcc-patches From rewriting mailman settings (Was: [Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions)

[Mark Wielaard]

Hi Gerald,

On Wed, Oct 04, 2023 at 12:17:48AM +0200, Gerald Pfeifer wrote:
> On Tue, 19 Sep 2023, Mark Wielaard wrote:
> >> Although there were some positive responses (on list and on irc) it is
> >> sometimes hard to know if there really is consensus for these kind of
> >> infrastructure tweaks. But I believe there is at least no sustained
> >> opposition to changing the gcc-patches mailman setting as proposed
> >> above.
> > This change is now done for gcc-patches.
> 
> Yeah, yeah, yeah. Thank you!

Thanks to the fsf-tech team who explained the setup they are using for
lists.gnu.org and everybody helping to test in the bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=29713

It seems to work well, but it does mean disabling most of the things
mailman can do, like filtering out HTML attachements, adjusting
headers, adding footers or subject prefixes, etc. And we did break at
least one workflow for people who were using DKIM signing and the
Errors-To header.

> >> And if there are no complaints at Cauldron we could do the same for
> >> the other patch lists the week after.
> 
> Sadly I missed Cauldron - have there been any complaints there?

No, the opposite. People seemed happy and there were some examples
shown where (on other lists, like binutils) From rewriting caused
issues for some tools relying on patchwork.sourceware.org.

> Can you adjust the gcc@gcc.gnu.org list and others @gcc.gnu.org as well?
> I for one would love to see that.

Being somewhat conservative doing that in steps. Last week we switched
the other gcc lists that receive patches (gcc-rust, libstdc++, fortran
and jit). This week looking at non-gcc lists on sourceware that use
patchwork (newlib, binutils, elfutils-devel, gdb-patches and
libabigail). Then if nothing breaks horribly more general lists if
people want.

Cheers,

Mark