Apologies, I've tried again and it worked first time. I'm not sure exactly what I did wrong before, but I was retrieving the key through multi-hop SSH, so some copy/pasting/pebkac error is feasible.

Thanks
JH

-- 
  John Hamelink

On Mon, 14 Aug 2023, at 2:27 PM, Conrad Hoffmann wrote:
> On 8/14/23 12:03, John Hamelink wrote:
>> Hi there,
>> 
>> I recently updated my PGP key, adding proof information in the form of a GPG notation. When I export the key to SourceHut in the format prompted by the placeholder on the textbox at https://meta.sr.ht/keys/pgp-keys, the form's validation fails with "No public keys suitable for encryption found.".
>> 

Hi there,

I recently updated my PGP key, adding proof information in the form of a GPG notation. When I export the key to SourceHut in the format prompted by the placeholder on the textbox at https://meta.sr.ht/keys/pgp-keys, the form's validation fails with "No public keys suitable for encryption found.".

The key is exported with `gpg --armor --export-options export-minimal --export F98B7F37E9EF3FCC0ED80715153DDFE9A54A9A4C` in my case.

My public key has been published successfully on OpenPGP.org: https://keys.openpgp.org/vks/v1/by-fingerprint/F98B7F37E9EF3FCC0ED80715153DDFE9A54A9A4C

I'm not sure what to do from here to make my key compliant with the form. Thanks.

JH
-- 
  John Hamelink

Hi Joshua,

Thanks for this patch, I've applied it!

Best,
JH

Joshua O'Connor <joshua@joshuao.com> writes:

> ---
>  README.md  | 2 +-
>  README.org | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>

Hi there,

After applying @prot's patches, I was able to get `git-email' to
install with Straight using the following snippet:

(straight-use-package
 '(git-email :type git :local-repo "~/code/jh/git-email" :build nil))
(require 'git-email)

I was going to submit a patch to the docs, suggesting users install
`git-email' in a manner similar to the above, I have no idea if
`:build nil' is indicative of a bug/code-smell or not.

Hope that helps!

> I am not aware of a workflow that involves Magit.  I have used
> git-email before: <https://git.sr.ht/~yoctocell/git-email>

Thank you for this Prot! I will give it a go. I subsequently also
found [piem], which I will explore soon as well - its focus seems
more on project maintenance, so might compliment git-email well.


[piem] <https://docs.kyleam.com/piem/index.html>

BTW I created a ticket for https://github.com/skeeto/elfeed/pull/457 to
preempt any reports from users on the issue.

https://todo.sr.ht/~johnhamelink/elfeed-paywall/1

Best,
JH

Hi Zabe,

Thanks for this detailed write-up - very helpful!

> To summarize: elfeed resets the entry's slots with the information
> provided by the feed whenever it fetches the feeds. To get around
> this, you can put your custom content in a metadata slot, since
> metadata slots are not reset. The problem now is that elfeed regularly
> deletes any elfeed-refs that aren't in the content slot of an entry. I
> posted a possible solution in the issue I linked, and just made a pull
> request to implement it: <https://github.com/skeeto/elfeed/pull/457>.

Yes indeed - I hadn't come across this bug yet, so thank you for
making me aware of it! I'll take a look at the PR you submitted as

Hi all,

For what it's worth, the first patch I received from a kind
contributor came in through my mailing list as an attachment ([See
here]).

I'm not sure what more could be done to direct contributors toward the
correct procedure (I note the excellent <https://git-send-email.io/>
website) - one thought was to restrict `.patch' attachments for emails
which aren't in the valid `git send-email' format, but then that might
have other undesirable side-effects on the mailing-list.

Also, does anyone have any recommended procedure for performing git
send-email from Emacs - preferably with Magit - or is everyone just

Hi Zabe,

Thank you for this - any help/advice and patches would be greatly
received.

When I updated the README, it was rather late and clearly I forgot to
test!

I'd also like to generate the .md file automatically so we don't have
to maintain two files in future (not that it's a particularly massive burden -
I'm just not a fan of chores!).

Thanks again,
John H (he/they)