Mailing list stripping off attachments

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Mailing list stripping off attachments

Thomas König
Hi,

looks like the new mailing list setup is stripping off patches. Example:

 https://gcc.gnu.org/pipermail/fortran/2020-
March/054050.html

The attachments are also not distributed via mail.

This breaks the gfortran review process. Could somebody please fix this?

Regards


Reply | Threaded
Open this post in threaded view
|

gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments)

Tobias Burnus-3
CC overseers.

they are not stripped – I do see them both in my inbox and at
https://gcc.gnu.org/pipermail/fortran/2020-March/054050.html

However, attachments of the "text/x-…" format (here: text/x-patch)
are no longer shown inline but have to be downloaded (with the
inconvenient suffix: .bin) – which is very inconvenient.

Cheers,

Tobias

On 3/9/20 9:23 AM, Thomas König wrote:

> Hi,
>
> looks like the new mailing list setup is stripping off patches. Example:
>
>   https://gcc.gnu.org/pipermail/fortran/2020-
> March/054050.html
>
> The attachments are also not distributed via mail.
>
> This breaks the gfortran review process. Could somebody please fix this?
>
> Regards
>
>
>
-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
Reply | Threaded
Open this post in threaded view
|

text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

Tobias Burnus-3
Hi Thomas, hi Overseers

I can confirm that those are stripped off!

I did sent an email with three attachments:
* test.txt (text/plain)
* test.diff (text/x-diff)
* the company's disclaimer

The attachment with 'text/x-diff' MIME was removed :-(
See: https://gcc.gnu.org/pipermail/fortran/current/054078.html

Tobias

-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
Reply | Threaded
Open this post in threaded view
|

List-Id header being stripped (was:Re: Mailing list stripping off attachments)

Richard Bradfield
On Mon, 9 Mar 2020 10:46:31 +0100, Tobias Burnus wrote:
> Hi Thomas, hi Overseers
>
> I can confirm that those are stripped off!
>
> I did sent an email with three attachments:
> * test.txt (text/plain)
> * test.diff (text/x-diff)
> * the company's disclaimer

It appears that since the migration (or whatever happened on the list
over the weekend), the List-Id header is also being stripped from
outbound mail. The last GCC mail I have where the header is intact was
from Friday 6th.

--
Richard
Reply | Threaded
Open this post in threaded view
|

Re: List-Id header being stripped

Richard Bradfield
On Mon, 09 Mar 2020 11:27:46 +0100, Andreas Schwab wrote:
> On Mär 09 2020, Richard Bradfield wrote:
>
> > It appears that since the migration (or whatever happened on the list
> > over the weekend), the List-Id header is also being stripped from
> > outbound mail.
>
> Worksforme.  These are the list-related headers of your mail:

Two user errors from me, my client was hiding some (but not all) extra
headers, and my filter rule was 'exactly equals [hidden email]' rather
than 'contains', post migration the List-Id includes the name portion,
so that broke which led to me checking the headers and missing them...

Thanks for looking!

--
Richard
Reply | Threaded
Open this post in threaded view
|

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

Jonathan Wakely-4
In reply to this post by Tobias Burnus-3
On Mon, 9 Mar 2020 at 10:28, Jakub Jelinek wrote:
> 1) the by date monthly list of mails used to be ordered newest to oldest
> mails first, now it is oldest to newest, so when dealing with new stuff one
> has to always scroll down

You can use #end to jump to the bottom.

> 6) there used to be a Raw text URL to grab the raw email, now there is nothing

That is something I need.

I use that to reply to mails that I don't have in my mailbox, because
I'm not sub'd to the list. With the raw text link you could download a
mailbox file of the mail, and so open it in your local MUA and reply
(with a correct In-Reply-To header, so that threading is properly
preserved).
Reply | Threaded
Open this post in threaded view
|

Re: text/x-* attachments stripped

Andreas Schwab
On Mär 09 2020, Jonathan Wakely wrote:

> I use that to reply to mails that I don't have in my mailbox, because
> I'm not sub'd to the list. With the raw text link you could download a
> mailbox file of the mail, and so open it in your local MUA and reply
> (with a correct In-Reply-To header, so that threading is properly
> preserved).

FWIW, you can also get them via NNTP from gmane.io.

Andreas.

--
Andreas Schwab, SUSE Labs, [hidden email]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: List-Id header being stripped

Florian Weimer
In reply to this post by Richard Bradfield
* Richard Earnshaw:

> On 09/03/2020 10:30, Florian Weimer wrote:
>> * Richard Bradfield:
>>
>>> It appears that since the migration (or whatever happened on the list
>>> over the weekend), the List-Id header is also being stripped from
>>> outbound mail. The last GCC mail I have where the header is intact was
>>> from Friday 6th.
>>
>> There weren't any List-Id headers before the migration.
>
> Yes there were (either that or the filters I've been using for years
> were psychic!)

Oh, right. They were added in 2006, after I had set up my filters
apparently. 8-/

So the difference is

List-Id: <gcc.gcc.gnu.org>

vs

List-Id: Gcc mailing list <gcc.gcc.gnu.org>

I guess now you need to perform a substring match.
Reply | Threaded
Open this post in threaded view
|

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

Thomas König
In reply to this post by Tobias Burnus-3
Hi,

I concur with what Jakub wrote. The new web interface is much less useful than the old one; a severe regression for developers, so to speak.

I also seem to have missed all discussion on this change (if there was anything). I do not understand why such a huge change was implemented that way, and who did this. Perhaos the person(s) responsible could speak up about this.

Will the old look and behavior be reinstated, at least in the most important aspects?
Reply | Threaded
Open this post in threaded view
|

Re: text/x-* attachments strippe

Gerald Pfeifer
On Mon, 9 Mar 2020, Thomas König wrote:
> I also seem to have missed all discussion on this change (if there was
> anything). I do not understand why such a huge change was implemented
> that way, and who did this. Perhaos the person(s) responsible could
> speak up about this.

Let's be careful - most people working on this are volunteers, and
it's great that they took care and spent evenings and weekends.

Could this have gone a bit smoother? Yes.  More collaborative? Maybe.

But it's been old system and quite an upgrade, so changes (including
some inconvenient ones) are to be expected.  I have found and reported
and (with the little I can) helped address some issues and will continue
to do so -- and am confident this is heading in the right direction.

Gerald
Reply | Threaded
Open this post in threaded view
|

Re: text/x-* attachments strippe

Frank Ch. Eigler-2
Hi -

Thanks for the kind words.

> Could this have gone a bit smoother? Yes.  More collaborative? Maybe.

We tried: the plan to migrate to mailman was included by reference
from the systemwide announcement blast two weeks ago:
https://sourceware.org/sourceware-wiki/MigrationStatus/

We continue to welcome advice & help.

- FChE
Reply | Threaded
Open this post in threaded view
|

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline

Nathan Sidwell-2
In reply to this post by Thomas König
On 3/9/20 9:57 AM, Thomas König wrote:
> Hi,
>
> I concur with what Jakub wrote. The new web interface is much less useful than the old one; a severe regression for developers, so to speak.

OMG I've just looked.  It's awful.  Sorry, but No.

For example
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/date.html just
gives a list of emails, no dates shown.  There's no indication what the
ordering is -- and apparently it is not most recent first.

nathan

--
Nathan Sidwell
Reply | Threaded
Open this post in threaded view
|

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline

Andreas Schwab
On Mär 09 2020, Nathan Sidwell wrote:

> For example https://gcc.gnu.org/pipermail/gcc-patches/2020-March/date.html
> just gives a list of emails, no dates shown.  There's no indication what
> the ordering is -- and apparently it is not most recent first.

Heading says:

Starting: Sun Mar 1 01:37:00 GMT 2020
Ending: Mon Mar 9 16:56:12 GMT 2020

Andreas.

--
Andreas Schwab, SUSE Labs, [hidden email]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

Martin Liška-2
In reply to this post by Tobias Burnus-3
On 3/9/20 11:25 AM, Jakub Jelinek wrote:

> On Mon, Mar 09, 2020 at 10:46:31AM +0100, Tobias Burnus wrote:
>> Hi Thomas, hi Overseers
>>
>> I can confirm that those are stripped off!
>>
>> I did sent an email with three attachments:
>> * test.txt (text/plain)
>> * test.diff (text/x-diff)
>> * the company's disclaimer
>>
>> The attachment with 'text/x-diff' MIME was removed :-(
>> See: https://gcc.gnu.org/pipermail/fortran/current/054078.html
>
> A different mail archiver is now used it seems.
> For the mails before the sourceware move, one can access the old one too,
> e.g.
> https://gcc.gnu.org/legacy-ml/gcc-bugs/2020-03/
> is the old one vs.
> https://gcc.gnu.org/pipermail/gcc-bugs/2020-March/
> I've been using the gcc-bugs mail archive all the time in the past, but I'm
> afraid pipermail at least in current configuration is significant step back
> and I'll likely just use my mailbox from now on.
> Some reasons:
> 1) the by date monthly list of mails used to be ordered newest to oldest
> mails first, now it is oldest to newest, so when dealing with new stuff one
> has to always scroll down
> 2) the dates and times of mails used to be shown (date as a section in the
> list, times in the left column), now there is nothing, so without clicking
> something it is hard to guess how exactly old it is
> 3) the columns were nicer (date, subject left justified, email right
> justified, now there are no columns)
> 4) some headers were shown, now there is nothing
> 5) emails used to be sanitized against harvesters, now they aren't
> 6) there used to be a Raw text URL to grab the raw email, now there is nothing
>
> Jakub
>

Hello.

I agree with Jakub that the listed feature were nicer about the previous mail list
archiver. On the other hand, I agree that we want to use something more recent that
is support and under some development. That said, we did we decide to use mailman-2.1
which is a legacy release that can be shortly out of support? Have you consider
using version 3.3.0?

I'm willing to customize the mail archiver, it should be quite simple.
Would it be possible to apply local patches for a RHEL package that's install
on the system?

Thanks,
Martin
Reply | Threaded
Open this post in threaded view
|

mailman customization

Martin Liška-2
Hello.

I believe we can quite easily customize mailman 2.1 to match our needs.
The biggest challenge I see is a proper testing as I don't see it easy
to set up a local mailman instance. I've got a patch that changes:

- by date sorting will be done in reverse order
- default link of e.g. https://gcc.gnu.org/pipermail/gcc-patches/2020-April/ will
   point to sorting by date
- email date is added to the listing

Further changes would be possible but I'll need a cooperation from oversees people.

Thanks,
Martin

mailman-improvement.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: mailman customization

Christopher Faylor-27
On Fri, Apr 03, 2020 at 05:58:51PM +0200, Martin Liška wrote:

>On 4/3/20 5:54 PM, Frank Ch. Eigler wrote:
>>Hi -
>>
>>>I believe we can quite easily customize mailman 2.1 to match our needs.
>>>The biggest challenge I see is a proper testing as I don't see it easy
>>>to set up a local mailman instance. I've got a patch that changes:
>>
>>I suppose we can do some local RPM respins - as long as these changes
>>are small and rare.
>
>That would be great. Should I create a git repo where we'll stack these changes?
>
>> Even with a deadish upstream, distro reporting
>>would be nice, at least at the centos/fedora point (?), as a reference
>>place to stash the patch and get us a bug#.
>
>Can you please do it for me as I don't have any experience with Fedora
>packaging?

If you're volunteering to maintain your patch, perhaps you should try
learning how to do that?

Reply | Threaded
Open this post in threaded view
|

Re: mailman customization

Christopher Faylor-27
In reply to this post by Martin Liška-2
On Fri, Apr 03, 2020 at 11:54:20AM -0400, Frank Ch. Eigler wrote:
>> I believe we can quite easily customize mailman 2.1 to match our needs.
>> The biggest challenge I see is a proper testing as I don't see it easy
>> to set up a local mailman instance. I've got a patch that changes:
>
>I suppose we can do some local RPM respins - as long as these changes
>are small and rare.  Even with a deadish upstream, distro reporting
>would be nice, at least at the centos/fedora point (?), as a reference
>place to stash the patch and get us a bug#.

I don't think most of the patch would be acceptable upstream since it
changes default behavior without any way to revert it.