From R Chowdhury to ~rjarry/aerc-devel
I accept the change of license. Regards, Rami On Mon, Feb 20, 2023 at 12:59 PM Robin Jarry <robin@jarry.cc> wrote: > > Hi all, > > as you may know, aerc is currently distributed under the MIT license. > This prevents from shipping aerc with notmuch support always enabled > (notmuch being GPL). > > After some multiple reported issues when building from source and
From to ~sircmpwn/aerc
On Tue, Aug 11, 2020 at 10:15, ARaspiK <araspik@protonmail.com> wrote: > On Tue Aug 11, 2020 at 9:56 AM WAT, Reto wrote: >> >> Did anyone test the patch below? >> I personally don't use oauth for my server. >> >> Any feedback would be appreciated. > > I just tested it (on gmail), and can confirm that it works (although > it > did once fail, for no apparent reason; retrying it then worked).
From to ~sircmpwn/aerc
Hey folks, Just wondering if anything happened with this patch? Forgive my ignorance: I'm not sure of the etiquette expected when submitting patches by mail to this project. I responded to a review, but don't know whether it's since been accepted, rejected, or ignored; and if the latter, is there an expectation that I would be advocating for it? Thanks, Rami
From Rami Chowdhury to ~sircmpwn/aerc
From: R Chowdhury <necaris@gmail.com> This piggybacks on the existing IMAP support, and uses the same configuration format (my local testing example has the IMAP and SMTP lines almost copy-pasted from one another). It's a little clumsy in that a new token is negotiated for every `Send()` command, but it's a start... --- commands/compose/send.go | 31 +++++++++++++++++++++++++++++++ lib/oauthbearer.go | 4 ++-- 2 files changed, 33 insertions(+), 2 deletions(-) diff --git a/commands/compose/send.go b/commands/compose/send.go [message trimmed]
From to ~sircmpwn/aerc
On Tue, May 26, 2020 at 07:44, Reto <reto@labrat.space> wrote: > Hi, > > On Mon, May 25, 2020 at 02:11:00PM -0400, Rami Chowdhury wrote: >> From: R Chowdhury <necaris@gmail.com> >> + if bearer.OAuth2.Endpoint.TokenURL == "" { >> + return fmt.Errorf("No token URL for OAuth Bearer - no worky") >> + } > > Get rid of those kinds of childish remarks please. > Treat the user like an adult and keep it somewhat professional.
From Rami Chowdhury to ~sircmpwn/aerc
From: R Chowdhury <necaris@gmail.com> This piggybacks on the existing IMAP support, and uses the same configuration format (my local testing example has the IMAP and SMTP lines almost copy-pasted from one another). It's a little clumsy in that a new token is negotiated for every `Send()` command, but it's a start... --- commands/compose/send.go | 31 +++++++++++++++++++++++++++++++ lib/oauthbearer.go | 4 ++-- 2 files changed, 33 insertions(+), 2 deletions(-) diff --git a/commands/compose/send.go b/commands/compose/send.go [message trimmed]
From Rami Chowdhury to ~sircmpwn/email-test-drive
From: Rami Chowdhury <rami.chowdhury@gmail.com> --- necaris | 1 + 1 file changed, 1 insertion(+) create mode 100644 necaris diff --git a/necaris b/necaris new file mode 100644 index 0000000..ef00156 --- /dev/null +++ b/necaris @@ -0,0 +1 @@ I have successfully _used_ git-send-email! [message trimmed]
From Rami Chowdhury to ~sircmpwn/email-test-drive
From: Rami Chowdhury <rami.chowdhury@gmail.com> --- necaris | 1 + 1 file changed, 1 insertion(+) create mode 100644 necaris diff --git a/necaris b/necaris new file mode 100644 index 0000000..51c592a --- /dev/null +++ b/necaris @@ -0,0 +1 @@ I'm about to try git-send-email [message trimmed]
From R Chowdhury to ~sircmpwn/sr.ht-discuss
On 2/16/20 7:10 PM, Cosmo Borsky wrote > Why not consider a resource limit on organizations? Sure, there's some overhead to keep track of, but this allows for better flexibility between individuals and organizations, and may serve as a good basis for metric collection on the organization's side (git repo size, build bandwidth and time, dispatch calls, etc) > > Resources keeps the model somewhat separate, where users pay for their account (which could be sponsored by an organization), and organizations would pay for usage, whether that's # of git repos, # of dispatch and builds per repo, and/or # of lists. > Sponsored organizations/projects could have a limit to these resources for "free", and it keeps introductory organization rates down for the bare minimum. Ooh, this is really interesting to me -- I find it easier to think about users and groups paying for largely distinct types of resources, and think it might be less confusing to users & groups looking at Sourcehut.
From R Chowdhury to ~sircmpwn/sr.ht-discuss
On 2/15/20 2:59 PM, Andrew Jones wrote: > I got around to updating my issue importer to use the PUT today, and have > triangulated an apparent issues with the API. The documentation on it > (https://man.sr.ht/todo.sr.ht/api.md#put-apiuserusernametrackerstracker-nameticketsticket-id) > seems to be pretty straightforward, but I am getting validation errors for > what appears to be a valid request. I'm sending my requests to > https://todo.sr.ht/api/trackers/test-tracker/tickets/6, after having created > the issue with ID 6, and using the API that assumes the username is that of > the user who owns the authentication token. The body of my request looks like: > > { > "status": "reported", > "resolution": "unresolved" > }