~emersion

France

https://emersion.fr

I'm Simon Ser, I write open-source software.

~emersion/soju-dev

Last active a day ago

~emersion/mrsh-dev

Last active 10 days ago

~emersion/public-inbox

Last active 20 days ago

~emersion/alps-dev

Last active a month ago

~emersion/drm-constraints

Last active 4 months ago
View more

Recent activity

Re: Broken DKIM header in mailing list 2 days ago

From Simon Ser to ~sircmpwn/sr.ht-discuss

Hi,

On Thursday, January 14th, 2021 at 11:19 AM, Greg Minshall <minshall@umich.edu> wrote:

> i see the same behavior i had seen before. though maybe we were even
> initially talking of different, dkim-signature, related problems?
>
> below i'll append the header as i saw it from a recent message from the
> list.

I've investigated the issue and wrote a lists.sr.ht patch:

https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/19785

[PATCH lists.sr.ht 2/2] Don't convert email encoding when archiving 2 days ago

From Simon Ser to ~sircmpwn/sr.ht-dev

This patch prevents archived messages from having a
Content-Transfer-Encoding which doesn't match the original message.

Python's email module will convert 8bit Content-Transfer-Encodings
to quoted-printable/base64 when using as_string. Replace with as_bytes.

Since the database stores the envelope as an UTF-8 string, this will
break non-UTF-8 messages.
---
 listssrht/process.py | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/listssrht/process.py b/listssrht/process.py
index 450018f9e522..0d36387db62f 100644
[message trimmed]

[PATCH lists.sr.ht 1/2] Encode e-mails to base64 for Celery 2 days ago

From Simon Ser to ~sircmpwn/sr.ht-dev

This patch allows 8bit messages to be forwarded as-is by lists.sr.ht.

We've been using str(mail) to convert a parsed message to a string.
However Python will convert any 8bit Content-Transfer-Encoding to
quoted-printable or base64 when formatting the string.

To prevent this, directly use the bytes coming from envelope.content.
However, Celery uses JSON to dispatch tasks data, and Python's stdlib
can't encode bytes.

To workaround this limitation, convert to base64.
---
 listssrht-lmtp       | 17 ++++++++++++-----
 listssrht/process.py |  8 ++++----
[message trimmed]

Re: [PATCH] Aggressively cache addressBook 4 days ago

From Simon Ser to ~migadu/alps-devel

The existing code isn't supposed to fetch images (see DataRequest).

Is the first page load still taking a very long time on your setup?
Maybe your CardDAV server isn't properly filtering the data returned.

[PATCH builds.sr.ht] images/freebsd: drop qemu-utils dependency 6 days ago

From Simon Ser to ~sircmpwn/sr.ht-dev

As stated in [1], qemu-utils has been broken for a while. For this
reason all of our FreeBSD image refreshes were failing.

However it turns out we don't actually need qemu-utils: qemu-img is
included in the qemu package itself. In fact, qemu and qemu-utils will
conflict as they both try to install qemu-img.

So let's just drop qemu-utils from our dependency list.

[1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252498

Suggested-by: Jan Beich <jbeich@FreeBSD.org>
---
[message trimmed]

Re: "Elasticsearch does not belong to Elastic" 7 days ago

From Simon Ser to ~sircmpwn/public-inbox

On Wednesday, January 20th, 2021 at 10:48 AM, Adrien Glauser <adrien.glauser@gmail.com> wrote:

> Even though I understand the spirit of this blog post and where it
> comes from, I have a simple question: What in your mind should
> companies offering FOSS software (Elastic, MongoDB) do in response to
> cloud services taking advantage of FOSS licenses? If you strike out
> "moving to a more restrictive license" from the list of possible
> countermeasures, what countermeasure or preemptive action would you
> recommend them?

Would the GPL license help? Maybe [1] is relevant.

[1]: https://drewdevault.com/2019/06/13/My-journey-from-MIT-to-GPL.html

Re: [PATCH v2] Request invite-notify to upstreams 8 days ago

From Simon Ser to ~emersion/soju-dev

> ... and do not forward INVITEs to downstreams that do not support the
> capability.
>
> The downstream capability can be permanent because there is no way for a
> client to get the list of people invited to a channel, thus no state can
> be corrupted.

Right. The cap is more of a marker saying "the client won't freak out when
receiving these INVITE messages".

> @@ -1341,6 +1342,9 @@ func (uc *upstreamConn) handleMessage(msg *irc.Message) error {
>  		}
>
>  		uc.forEachDownstream(func(dc *downstreamConn) {

Re: [PATCH] Correctly handle empty IRC messages 8 days ago

From Simon Ser to ~emersion/soju-dev

Ah, thanks. This patch won't quite work as-is because  we need to
update go.sum as well.

Can we update all dependencies while at it?

   go get -u ./...
   go mod tidy

Re: Broken DKIM header in mailing list 15 days ago

From Simon Ser to ~sircmpwn/sr.ht-discuss

On Tuesday, January 12th, 2021 at 8:01 PM, Greg Minshall <minshall@umich.edu> wrote:

> is there any one line explanation of the problem in the generation of
> the header? i'm curious.

Yes, this was an issue with my sendmail milter implementation:

https://github.com/emersion/go-milter/commit/66cc0fbd0b5ea990a71450f26c13bac4f5da1192

Postfix doesn't handle CRLF for data coming from milters, and
automatically adds a CR before any LF. So the header lines inserted by
the milter had some \r\r\n sequences as you reported.