Am Do., 11. Apr. 2019 um 17:21 Uhr schrieb Mike Banon <mikebdp2@gmail.com>:
message: "<memory at 0x7f696b2a54c8>", "<memory at 0x7f696b2a51c8>"
and so on.
 
Maybe a segmentation fault somewhere?
No, it's just python being python. That thing doesn't say "it's crashing at that position", but "the object I'm printing is at that address" because apparently the data type doesn't support anything better.
The issue is discussed over at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/6K5ARCTDUYJ5RZYDFST2DF4GTDPCMPTS/ and I applied that patch locally which fixes it, so for now we should be good.

Thank you for the report!

P.S. I miss the old Pipermail: with its' convenient old school web UI,
short clear links and working attachments... :P
The short clear links had one very distinct disadvantage: they are unstable. We have a couple of URLs pointing into the pipermail subtree in our source trees that point to the wrong email. The scheme that is now used is stable because it uses a (URL-friendly) hash of the message ID. It's also more verbose because it encodes the entire email address, but that's because mailman3 supports serving different domains (whereas before, seabios@coreboot.org or coreboot@seabios.org would work as well).

As for the UI not being old school, well... Apparently nobody on the entire internet cares enough to add server side rendering to hyperkitty.


Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado