Your message dated Mon, 13 Jul 2020 18:39:20 +0200 with message-id <a96994cf-6e7a-9f6b-cd58-233564589bd4@web.de> and subject line Re: reportbug/mailer.py: xdg-email MUA encodes mailto URL instead of using xdg-email command-line parameters has caused the Debian Bug report #964847, regarding reportbug/mailer.py: xdg-email MUA encodes mailto URL instead of using xdg-email command-line parameters to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 964847: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964847 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: reportbug/mailer.py: xdg-email MUA encodes mailto URL instead of using xdg-email command-line parameters
- From: Paul Wise <pabs@debian.org>
- Date: Sat, 11 Jul 2020 09:54:48 +0800
- Message-id: <[🔎] 1fe0e0d2126599f6a23170820f7471bc8b05e26f.camel@debian.org>
Package: python3-reportbug Version: 7.7.0 Severity: normal File: /usr/lib/python3/dist-packages/reportbug/mailer.py The xdg-email MUA maps to the Mailto class, but the Mailto class fully encodes the Mailto URL, while xdg-email takes command-line parameters for the CC, BCC, Subject, mail body and attachments. I suggest that the xdg-email MUA option should use the command-line parameters instead, since xdg-email could do things differently for MUAs that have better mechanisms than mailto: for passing items to their composers. For example some MUAs could support long mail bodies via xdg-email but not via mailto: URLs. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (850, 'buildd-testing-proposed-updates'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-reportbug depends on: ii apt 2.1.7 ii file 1:5.38-5 ii python3 3.8.2-3 ii python3-apt 2.1.3 ii python3-debian 0.1.37 ii python3-debianbts 3.0.2 ii python3-requests 2.23.0+dfsg-2 ii sensible-utils 0.0.12+nmu1 python3-reportbug recommends no packages. Versions of packages python3-reportbug suggests: ii reportbug 7.7.0 -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWiseAttachment: signature.asc
Description: This is a digitally signed message part
--- End Message ---
--- Begin Message ---
- To: Paul Wise <pabs@debian.org>, 964847-done@bugs.debian.org
- Subject: Re: reportbug/mailer.py: xdg-email MUA encodes mailto URL instead of using xdg-email command-line parameters
- From: Nis Martensen <nis.martensen@web.de>
- Date: Mon, 13 Jul 2020 18:39:20 +0200
- Message-id: <a96994cf-6e7a-9f6b-cd58-233564589bd4@web.de>
- In-reply-to: <[🔎] 67c754d47bfd4db5b542b15164c0a9c4e6015e02.camel@debian.org>
- References: <[🔎] 1fe0e0d2126599f6a23170820f7471bc8b05e26f.camel@debian.org> <[🔎] 1fe0e0d2126599f6a23170820f7471bc8b05e26f.camel@debian.org> <[🔎] b69649aa-5e4c-5e42-f952-ebafe7774c92@web.de> <[🔎] 67c754d47bfd4db5b542b15164c0a9c4e6015e02.camel@debian.org>
> That is an internal implementation detail that cannot and should not be > relied on. It would be much cleaner to rely on the published interface > that xdg-email specifies that it provides. Both the --help output and the manual page xdg-email(1) do specify explicitly that passing a mailto uri is supported, so I think it is part of the published interface. I'm closing the bug accordingly. You are right that arguing on the basis of internal implementation details is not always a good idea. Thank you for pointing this out.
--- End Message ---