Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Conversation

polarathene
Copy link
Member

@polarathene polarathene commented Feb 12, 2025

Description

Since we have a new release coming up, I figured I'd look into bumping our manually installed software.

  • Updates:
    • Rspamd 3.8.4 => 3.11.0 (implicit as no version pinning)
    • fts-xapian 1.7.13 => 1.9.0
      • NOTE: The maintainer didn't tag the release with proper semver, hence change to 1.9 is correct
      • Previously 1.7.12 (DMS v14), updated to 1.7.13 (#4095)
    • jaq 2.0.0 => 2.1.0
      • Previously 1.3.0 (DMS v14), updated to 2.0.0 (#4190)
    • Dovecot CE 2.3.x (invalid for Debian 12) => 2.4.x (potentially incompatible, but isn't broken at build time like current 2.3 series for Debian Bookworm is)
  • Revised comments and logs for consistency + improved context.
  • Dovecot + Rspamd repo adding + package install now consistent.
    • Prior images of DMS will now fail to build from the Dovecot CE repo as the GPG key no longer exists and returns 404 (no redirect), instead a -2.3 or -2.4 suffix is required. The repo info page also changed from gpg --import / gpg --export to using gpg --dearmor like Rspamd does.

    • http:// => https:// for rspamd's repo (this isn't required, Debian configures it's own repo URLs with plain HTTP)

    • upstream- prefix used for GPG keys we create. Purely cosmetic for grouping.

    • /etc/apt/trusted.gpg.d => /usr/share/keyrings is where keys should be stored now (Debian has keys here already), more info:

      Adding a key to /etc/apt/trusted.gpg.d is insecure because it adds the key for all repositories. This is exactly why apt-key had to be deprecated.

      Once a future release of Debian provides a newer release of apt (DMS edge currently has apt 2.6.1) we can automate conversion of the current .list files created to DEB822 .sources (Debian 12 already has this format, but .list remains compatible for the time being), which will allow for the terser .list format:

      Since apt 2.9.24 (released January 2025), you can run apt modernize-sources to automatically migrate all your .list files to DEB822


Other services not yet bumped

I've requested Fail2Ban to push out a new release. There appears to be some changes / fixes for mail related software, the commit history is a bit messy but the changelog seems to represent most of it at a glance.

I thought we were still pulling in getmail6 from an external source rather than a debian package (6.18.11-2), as I had wanted to bump it (may need to wait until Debian 13 then). Getmail from 6.19.0 adds the mark_read option, which allows for matching Fetchmail behaviour to mark retrieved mail with \Seen. That's presently a difference I have noticed between the two services.


Lack of version pinning

Rspamd's repo seems to only carry one version, making it unreliable for building past images of DMS since we cannot pin the package by version if the package gets removed.

# This shows that each repo is only offering 1 package each:
# bookworm (stable) + rspamd (unknown)
# Normally if a repo carries multiple packages we'd get the full list via `-a`
$ apt list -aqq rspamd
rspamd/unknown 3.11.0-1~90a175b45~bookworm amd64
rspamd/stable 3.4-1 amd64

# For additional clarity, this similar command will detail the source repo URL:
# NOTE: This is run from a debian:12-slim container instead of DMS, hence no rspamd installed
$ apt-cache policy rspamd
rspamd:
  Installed: (none)
  Candidate: 3.11.0-1~90a175b45~bookworm
  Version table:
     3.11.0-1~90a175b45~bookworm 500
        500 https://rspamd.com/apt-stable bookworm/main amd64 Packages
     3.4-1 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages

The Dovecot repo appears to be the same with version specific repos and a latest variant. An example of a multi-version deb repo is Caddy via Cloudsmith.

Type of change

  • Improvement (non-breaking change that does improve existing functionality)

Checklist

  • My code follows the style guidelines of this project
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • New and existing unit tests pass locally with my changes
  • I have added information about changes made in this PR to CHANGELOG.md

@polarathene polarathene added service/dovecot area/scripts area/features kind/update Update an existing feature, configuration file or the documentation labels Feb 12, 2025
@polarathene polarathene added this to the v15.0.0 milestone Feb 12, 2025
@polarathene polarathene self-assigned this Feb 12, 2025
@polarathene polarathene marked this pull request as ready for review February 13, 2025 05:18
@polarathene
Copy link
Member Author

polarathene commented Feb 13, 2025

I think this is worth merging to v15 before the freeze.

Apologies for the messy changelog diff. Rough summary of changelog update:

  • I have moved any mention of version updates into a single grouped entry
  • Shifted some getmail related changes away from the verbose breaking changes section since they're not breaking.
  • Minor revisions.

Updating the compile.sh package is failing:

Resolved
/usr/bin/dh_make:10: DeprecationWarning: 'nis' is deprecated and slated for removal in Python 3.13
  import nis

Maintainer Name     : root
Email-Address       : root@docker-mailserver.invalid
Date                : Thu, 13 Feb 2025 05:20:13 +0000
Package Name        : dovecot-fts-xapian-1.9
Version             : 1.9
License             : gpl2
Package Type        : single
Currently there is not top level Makefile. This may require additional tuning
Done. Please edit the files in the debian/ subdirectory now.

cp: cannot stat 'PACKAGES/DEB/control': No such file or directory
ERROR: process "/bin/bash -e -o pipefail -c /bin/bash /build/compile.sh" did not complete successfully: exit code: 1

EDIT: Resolved. This was due to PACKAGES/ being removed from 1.7.17 onwards. I got familiar with the tooling and repo, making adjustments to support building newer versions of the project.

Copy link
Member

@georglauterbach georglauterbach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change set LGTM. Tests are failing, though. Do you need assistance?

@polarathene
Copy link
Member Author

polarathene commented Feb 13, 2025

Tests are failing, though. Do you need assistance?

I resolved them.

Just waiting on the ARM64 build so I can restart the failing test case which is unrelated to this PR (we have the setup CLI tests running in the parallel set when they should actually be in serial since it's prone to race conditions otherwise).


So rough summary of this PR (lot of diff noise, minor improvements, better inline docs):

  • Externally installed software version bumps, nothing seems breaking.
  • compile.sh required some minor modifications to support newer releases due to upstream changes. For the most part it's the same logic, just with long option names and extra commentary.
  • packages.sh likewise got tidied up + extra commentary, nothing really changed logically.
  • Dovecot repo now supports building with 2.4 (2.3 would fail with bookworm).
  • Changelog shuffling some entries + minor changes.

@polarathene polarathene enabled auto-merge (squash) February 13, 2025 08:36
@polarathene polarathene merged commit 425d116 into master Feb 13, 2025
7 checks passed
@polarathene polarathene deleted the chore/update-external-packages branch February 13, 2025 12:16
@casperklein
Copy link
Member

LGTM 👍

Nothing to complain, just a thought:

The purpose of compile.sh was to provide a place for custom builds (maybe more than one in the future). The old function name _compile_dovecot_fts_xapian was better in my opinion. That made it more explicit about what is done + in the future, other _compile_XXX functions could be added.

@polarathene
Copy link
Member Author

The purpose of compile.sh was to provide a place for custom builds (maybe more than one in the future).

Oh right, that's a fair point. Although if that were to happen we could probably have a directory with separate scripts for each and have compile.sh call each? I'd rather that than a single file cramming it all in 😓

@casperklein
Copy link
Member

Oh right, that's a fair point. Although if that were to happen we could probably have a directory with separate scripts for each and have compile.sh call each?

Yes, that's an option I've also thought of.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/features area/scripts kind/update Update an existing feature, configuration file or the documentation service/dovecot

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.