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. 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 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. Then the working binaries will migrate just fine. A less than ideal solution, but it's a decision you ultimately get to make as Maintainer. --Daniel
signature.asc
Description: PGP signature
