Package: mlmmj
Version: 1.5.0-1
X-Debbugs-CC: Chris Knadle <
Chris.Knadle@coredump.us>, Michael Jeanson <
mjeanson@debian.org>, Thomas Goirand <
zigo@debian.org>,
dxld@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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEV6G/FbT2+ZuJ7bKf05SBrh55rPcFAmf/nskACgkQ05SBrh55 rPcU+hAAjuNbaOICt+urGFnOyl5sq0mwOC6TEUmFoXvDLOz4rYpwYgwiznBLmdHC rYjsCCOYnaevKsbxERVncOlyhasxEpCsDsF5jRtKK3/jUFViQukZDdqtaVQsCQMU d1dmTz/A034tNIANJpPJGjGGdO/R92/LEyMe7tKDLmwh4Gs5A+zGjzmesoqoWwCe RXoF8MlICnRrD5V13jkD2XIfTGaxA01iU3IoYB4WupVva0jupd3enqKUId/ExVsL VpT2EV+K9l7guiczRZEzdg0xLTuvaFgvavgklNGFB97iCh3XdhOO3Burl2g6D7OQ pOEC14JlfyXM1nMFk2ueyqtS2nvrpUUu7fObw2v4RL+1MWhe5wM7cF4Sy0FYbo4g JApKnbff6Z3Jxnu0QHBa+mXt6G931jEaFz2iuJ+rmQII5ORcJoeEMKXAMlohfyFE f5VHMb/X4QMemvBIExjwNbYlmN/wfIxTOzVmyTTncV95azrvzfdFLRdNVGnl82u+ HCWW1tmyZxM1+OAKX0mCIdprswjWrm2GKHBowAqZALHf3N2zGljukeR7699AQdT+ u8PURFbqytLYCCTMf4hHR9fW3rXrxnXzZyMxyxEM8m5kYZ08rxgu6wcY1osV4NkY Riuf9KFvyzX68yawlZYDAnPmD+pLro6+U8nVvTFAcqybBgPesm4=
=NoWY
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)