Re: [pacman-contrib] [PATCH] paccache: Skip .sig files when globbing candidates for removal
On 02/21/2018 03:17 PM, Maxim Baz via pacman-contrib wrote: This is not a valid patch. It appears to have been sent with: Content-Disposition: inline User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Did you change `mail.content_disposition_type = 0` and send this email as an attachment by any chance? The raw contents of the (inline attachment) patch are: Basically allow any extension after '.tar' except '.tar.sig'. This is needed to correctly count the possible candidates for removal. Signature files are correctly considered later in the script. Fixes FS#57503 Signed-off-by: Maxim Baz <git@maximbaz.com> ---  src/paccache.sh.in | 2 +-  1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/paccache.sh.in b/src/paccache.sh.in index 49680be..94bedfa 100644 --- a/src/paccache.sh.in +++ b/src/paccache.sh.in @@ -308,7 +308,7 @@ for cachedir in "${cachedirs[@]}"; do     # note that these results are returned in an arbitrary order from awk, but     # they'll be resorted (in summarize) iff we have a verbosity level set.     IFS=$'\n' read -r -d '' -a cand < \ -      <(printf '%s\n' "$PWD"/*.pkg.tar?(.+([^.])) | pacsort --files | +      <(printf '%s\n' "$PWD"/*.pkg.tar?(.+([^.])) | grep -v '\.sig$' | pacsort --files |           pkgfilter "$keep" "$scanarch" \              "${#whitelist[*]}" "${whitelist[@]}" \              "${#blacklist[*]}" "${blacklist[@]}") -- 2.16.2 The best way to send a patch is using git-send-email(1) This way will definitely not work, because of file corruption. -- Eli Schwartz Bug Wrangler and Trusted User
On 02/21/2018 03:59 PM, Eli Schwartz wrote:
On 02/21/2018 03:17 PM, Maxim Baz via pacman-contrib wrote:
This is not a valid patch. It appears to have been sent with:
Content-Disposition: inline User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
Did you change `mail.content_disposition_type = 0` and send this email as an attachment by any chance?
Sorry, this was only partially true. The patch was broken anyways because of linebreaks and other fun chars, but my issue with it being an "attachment" is because this list seems to have been configured to relay messages as message/rfc822. As Johannes pointed out, this is the technically correct way to preserve DKIM signatures when the mailing list modifies the From and Subject lines to add the list name into the subject... if only every client out there (or even most of them) actually supported it... -- Eli Schwartz Bug Wrangler and Trusted User
participants (1)
-
Eli Schwartz