Package: sponsorship-requestsSeverity: wishlistX-Debbugs-Cc: debian-mentors@lists.debian.orgX-Debbugs-Cc: service@cevinpalmer.comDear mentors,I am looking for a sponsor for my package "palmer-mail": * Package name : palmer-mail Version : 1.4.0-1 Upstream contact : Cevin Palmer <cevin@cevinpalmer.com> * URL : https://cevinpalmer.com/palmermail/ * License : GPL-3+ * Vcs : https://codeberg.org/cevinpalmer/palmer-mail Section : mailThe source builds the following binary package: palmer-mail - native email and calendar client for LinuxTo access further information about this package, please visit thefollowing URL: https://mentors.debian.net/package/palmer-mail/Alternatively, you can download the package with 'dget' using thiscommand: dget -x https://mentors.debian.net/debian/pool/main/p/palmer-mail/palmer-mail_1.4.0-1.dscChanges for the initial release: palmer-mail (1.4.0-1) unstable; urgency=medium . * Initial release. (Closes: #1146293)Some notes that may save you time:Palmer Mail is a Qt 6 mail and calendar client written in Python. It speaks IMAP and SMTP, and additionally supports Proton Mail throughProton's own Bridge and Microsoft 365 via OAuth 2.0.Two things distinguish it from the mail clients already in the archive. Proton Mail is a first-class backend rather than a generic IMAP account: the client understands Bridge's folder and label namespace directly, including where Proton's semantics differ from IMAP's. And a selection of messages can be exported to CSV or JSON, with bodies as plain text and attachments extracted -- no shipping Linux mail client does this without a third-party add-on.The client enforces TLS certificate verification with no user-facing override, blocks remote content in messages by default, and stores all credentials in the system keyring. It contains no telemetry and makes no network connection other than to the mail servers a user configures.lintian reports no tags at all on the binary package, and no errors on the source. The one source warning is newer-standards-version, an artefact of my local lintian predating Policy 4.7.4.This is my first package. I am not a Debian Developer or Maintainer and I intend to maintain it myself.Regards,Cevin Palmer

Dear mentors,

I am looking for a sponsor for my package "palmer-mail":

  * Package name : palmer-mail
    Version : 1.4.0-1
    Upstream contact : Cevin Palmer <cevin@cevinpalmer.com>
  * URL : https://cevinpalmer.com/palmermail/
  * License : GPL-3+
  * Vcs : https://codeberg.org/cevinpalmer/palmer-mail
    Section : mail

The source builds the following binary package:

   palmer-mail - native email and calendar client for Linux

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/palmer-mail/

Alternatively, you can download the package with 'dget' using this
command:

   dget -x
https://mentors.debian.net/debian/pool/main/p/palmer-mail/palmer-mail_1.4.0-1.dsc

Changes for the initial release:

  palmer-mail (1.4.0-1) unstable; urgency=medium
  .
    * Initial release. (Closes: #1146293)

Some notes that may save you time:

Palmer Mail is a Qt 6 mail and calendar client written in Python. It
speaks IMAP and SMTP, and additionally supports Proton Mail through
Proton's own Bridge and Microsoft 365 via OAuth 2.0.

Two things distinguish it from the mail clients already in the archive.
Proton Mail is a first-class backend rather than a generic IMAP account:
the client understands Bridge's folder and label namespace directly,
including where Proton's semantics differ from IMAP's. And a selection
of messages can be exported to CSV or JSON, with bodies as plain text
and attachments extracted -- no shipping Linux mail client does this
without a third-party add-on.

The client enforces TLS certificate verification with no user-facing
override, blocks remote content in messages by default, and stores all
credentials in the system keyring. It contains no telemetry and makes no
network connection other than to the mail servers a user configures.

lintian reports no tags at all on the binary package, and no errors on
the source. The one source warning is newer-standards-version, an
artefact of my local lintian predating Policy 4.7.4.

This is my first package. I am not a Debian Developer or Maintainer and
I intend to maintain it myself.

The original submission lost its line breaks in transit. Resending it
readable — apologies for the noise.

Regards,
Cevin Palmer

Didn't Codeberg forbid LLM output?

Anyway, the packaging is as sloppy as the code itself, and the ITP has an
ongoing discussion betwen a human and a bot about whether this should be
packaged. I don't recommend sponsoring this.

I didn't attempt to test the MUA already because of the present shape of
`pyproject.toml` in general and the requirement of `pytest` with only
`pytest>=8.0` in particular.  It still might be functional, but feels "off" as
in "the package did not receive enough care" for a package to be introduced in
2026 into the Debian ecosystem.

Thanks Norwid for your kind feedback,
1.4.0-2 is uploaded, addressing the points raised.

pyproject.toml has been reworked: the deprecated license table replaced
with a PEP 639 SPDX declaration and license-files, [project.urls] added,
wheel dropped from build-system.requires, and the test extra separated
from the linting tools.

You were right that the empty test override was the real problem. The
build now runs the test suite -- 2,199 tests, with Build-Depends
covering them. The GUI tests remain excluded because pytest-qt is not
packaged in Debian, and debian/rules now says so rather than leaving it
unexplained.

Thank you for the specifics; they were useful.

Regards,
Cevin Palmer

The most recent upload to the mentors page (2026-09-05 01:08 UTC, currently labeled as upload #2) added issues the earlier upload (2026-09-04 05:08 UTC, currenly labeled as #1) did not have.

- Because `palmer-mail` is unknown to Debian (by the query
https://tracker.debian.org/search?package_name=palmer-mail), the introduction
  requires d/control to link to the ITP bug (one type of the WNPP bug tickets) -
  as in upload by September 4.
- Check why `VCS field` (about the repository to package) is dysfunctional in
  uploads to the mentors page.  Unable to tell if there might be an issue with /
  a gap of support for codeberg, one could try salsa (as a good number of
  packages use).

  A repository to package to Debian typically is not the upstream repository
  (where the program is developed).  Because down the road, maybe once you need
  patches to the commit history specific to packaging to Debian, but irrelevant
  to Fedora.  Their rules and best practices may differ from the ones here in
  Debian; i.e. to ease house keeping.
- Version numbering on `-1` (in `1.4.0-1`) and `-2` (in `1.4.0-2`).  The counter
  about the upload to the mentors page (`Upload #1`, `Upload #2`, etc) is not
  the `-debian-revision` (see section 5.6.12 Debian policy).  To introduce
  upstream version `1.4.0` to Debian, this field should be `1.4.0-1` -
  regardless of the number of iterations necessary to satisfy checks on the
  mentors page, either automatic or by a human reviewer / potential sponsor for
  an upload.  A `1.4.0-2` can become useful later (the source-only upload).
- Current `d/changelog` (`90b6cbeda7` on codeberg) reads more about improving
  the program (what I expect to happen in an upstream repository) than about
  packaging only.  Compare with already admitted packages, for instance
https://salsa.debian.org/debichem-team/jmol/

  The presence of multiple version entries in `d/changelog` (about packaging)
  however contradicts with the presence of only one commit to the repository to
  package.  In the salsa repository about packaging Jmol, code -> tags for
  instance allows to travel in time to specific commits tagged, code -> branches
  to access the three mandatory branches `pristine-tar`, an upstream and a
  default branch.  The codeberg repository might serve well enough as an
  upstream reference, because of the missing branches it however is not fit for
  packaging.  As above, to prepare the package is easier to manage if it is in a
  repository separate from the one about the upstream reference.
- In current `d/control` (`90b6cbeda7`), there is a great number of comments.
  That's unusual, unwanted clutter.  Some dependencies explicitly define a
  minimal version (an advantage), though the pattern is not consistently
  applied.
- `d/watch` still is `version=4` instead of current `Version: 5`.
- `pyproject.toml` (still) includes a great number of comments.  Some don't
  belong here (e.g., the groff command `.TH` for a man page), or are not needed
  (e.g., definition of the version tuple, notes on Ubuntu).  This pattern is
  similar to the one of source code written by some LLMs yet without subsequent
  manual lint.
- Personally, I no longer retain a `requirements.txt` while organizing Python
  dependencies within `pyproject.toml`.  Regarding `pytest`: for more important
  scripts, I tend to specify its usage in further detail, for instance

```pyproject.toml
[tool.pytest]
pythonpath = ["src"]
testpaths = ["tests"]
filterwarnings = ["ignore::pytest.PytestCacheWarning"]
markers = [
    "blackbox: test series from the outside",
    "imported: a test which imports a function of the script",
]
minversion = "9"
log_level = "INFO"
strict = true
addopts = ["-ra"]
```

Regards,
Norwid