Hello Eric, On 12/30/21 20:17, Eric Wong wrote: > Uwe Kleine-König wrote: >> Hello, >> >> adding the Debian Perl Group to Cc, maybe they can help here. >> (for context look at https://bugs.debian.org/1002219) >> >> On 12/30/21 10:12, Uwe Kleine-König wrote: >>> I got a bug report against the public-inbox 1.6.1 package about a >>> failing test, see below for the whole output. I didn't have time yet to >>> look into it, so this is just a heads up to make you aware. If someone >>> has a hint what to do, this would be greatly appreciated. Maybe just >>> updating to 1.7 will help? >>> >>> Best regards >>> Uwe >>> >>> On 12/21/21 17:34, Lucas Nussbaum wrote: >>>>> #   Failed test 'filename decoded' >>>>> #   at t/eml.t line 407. >>>>> #          got: '=?utf-8?q?vtpm-makefile.patch?=' >>>>> #     expected: 'vtpm-makefile.patch' >>>>> # Looks like you failed 1 test of 146. >>>>> t/eml.t ...................... >> >> I can reproduce this problem with 1.6.1 checked out. I played a bit around >> (suffering from my weak perl foo) and found that when I downgrade >> libemail-mime-perl from 1.952-1 (i.e. Debian unstable's version) to 1.949-1 >> (i.e. Debian stable's version), this works. >> >> The reproducer is: >> >> $ perl -e 'use Email::MIME; print Email::MIME->new("Content-Type: >> text/x-patch; name=\"=?utf-8?q?vtpm-fakefile.patch?=\"\nContent-Disposition: >> attachment; filename=\"=?utf-8?q?vtpm-makefile.patch?=\"\n\n")->filename;' >> >> which emits "vtpm-makefile.patch" with 1.949-1 (as public-inbox expects),. >> but =?utf-8?q?vtpm-makefile.patch?= with 1.952-1. >> >> So the key question is: Is the test correct and his is a regression in >> libemail-mime-perl, or is the test wrong and we need to fix the test (and >> PublicInbox::Eml)? > > I thought I sent a fix to this; but I nuked the root FS on one of > my workstations on accident :< Still recovering... Oh, good luck in restoring your precious data. Thanks for your patch. I just uploaded public-inbox with this change to fix the bug. I still wonder if this is a regression in Email::MIME, or just a wrong expectation. In the first case I'd open a bug against libemail-mime-perl. Bisecting in https://github.com/rjbs/Email-MIME.git yields https://github.com/rjbs/Email-MIME/commit/8a7cffd2b1091ff1a750d541a85e1813a6747b72 as breaking commit. So this looks like an intended change. Best regards Uwe