Hello, Daniel
On 4/16/25 08:13, Daniel Gröber wrote:
Package: mlmmj
Version: 1.5.0-1
X-Debbugs-CC: Chris Knadle <chris.kna...@coredump.us>, Michael Jeanson
<mjean...@debian.org>, Thomas Goirand <z...@debian.org>, d...@darkboxed.org
Hi Chris,
I'm moving this to the BTS for visibility.
Okay that's good -- I would have opened a bug report on this today if
you hadn't. ;-)
On Wed, Apr 16, 2025 at 12:03:42AM -0400, Chris Knadle wrote:
On further looking at Michael's Git repository and saw how the Debian build
goes through an upstream test suite, I decided to incorporate the work that
was done into an MLMMJ 1.5.0 package, and I uploaded that to Debian this
evening before the Trixie build freeze.
Thank you! I was meaning to but lost track of it. Did you figure out the
necessary exim config change to fix the new tainting logic too? I have
something locally I've been meaning to post about.
I'm continuing to run MLMMJ with Exim4 as before without having to make
any configuration changes. The Debian 11 release notes section 5.1.17
discusses the MLMMJ configuratin for Exim4, which makes clear that the
"tainted" variables such as $local_part and $domain can't be used as a
variable *to access a file or a directory*, such as mail delivery to
/var/mail/$local_part -- but the MLMMJ configuration does neither of
those things. That includes the configuration in /etc/aliases.
In other words -- using $local_part and $domain *is okay* as long as
it's not used to access a file or directory. Since the Exim4
configuration for MLMMJ doesn't do that, as far as I can tell there are
no configuration changes required for the documentation.
((I already have to go plead with release team over dovecot-fts-flatcurve
no need for yet another package to do that for ;-))
At the moment I don't have a good way of doing a build on the array of
Debian release architectures, so I didn't test that before the
upload.
That's fine. This is how many DDs seem to work. You can use porterboxes for
this but honestly it's too much of a hassle for pre-upload testing. Many
use experimental so as to not disrupt unstable users.
Often perfect is the enemy of good enough anyway. Especially with a freeze
looming. I find often as soon as there's activity other people might jump
in to help, so it's really vital to Debian functioning well to just do
*something* even if it's (still) broken.
Think of it this way: nothing attracts motivated nerds quite like hard
problems to solve. As maintainers we should endeavor to create as many
visible and well understood problems as possible :D.
Which is what I tried to do months ago as you'll recall.
Remember: reverting to an old upload (using +really) is always possible.
Unfortunately there are a bunch of Debian release architectures that the
build fails for, and I'm hoping to get hints as to how to fix that in the
next month before the hard freeze so that MLMMJ 1.5.0 can make it to the
Trixie release.
While not the first thing we should try, process wise you can also declare
architectures mlmmj doesn't build on as unsupported by asking ftp-master to
RM them from the archive.
Note: the build failures in the logs for MLMMJ are due to *test suite*
failures on certain architectures -- the build itself of MLMMJ succeeds
before the tests. This leads me to wonder whether the tests are
correctly catching failures, or if the tests may be catching some "false
positives" on certain architectures. I also wonder whether there were
"hidden issues" on other architectures previously that weren't detected
until now, because the build tests are a new addition, as far as the
package in Debian.
If the test suite failures are due to the test suite itself then there
should be a way to conditionally not run the tests on the architectures
where the tests fail.
-- Chris
Chris Knadle
chris.kna...@coredump.us
