~necaris

Recent activity

Re: Relicensing aerc to GPL 1 year, 9 months ago

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

Re: [PATCH v2] Add `oauthbearer` support for SMTP 4 years ago

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).

Re: [PATCH v2] Add `oauthbearer` support for SMTP 4 years ago

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

[PATCH v2] Add `oauthbearer` support for SMTP 4 years ago

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]

Re: [PATCH] Add `oauthbearer` support for SMTP 4 years ago

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.

[PATCH] Add `oauthbearer` support for SMTP 4 years ago

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]

[PATCH v2] Demo that I can follow some (more) instructions 4 years ago

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]

[PATCH] Demo that I can follow some instructions 4 years ago

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]

Re: Supporting user groups/organizations on SourceHut 4 years ago

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.

Re: todo.sr.ht - status + resolution on API 4 years ago

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"
> }