From Piotr Masłowski to ~rjarry/aerc-devel
Hello everyone, When you forward a message as an attachment, aerc correctly sets its mime type as `message/rfc822` but then it uses base64 as its `Content-Transfer-Encoding`. This is explicitly forbidden by the RFC2046 5.2.1: > No encoding other than "7bit", "8bit", or "binary" is permitted for > the body of a "message/rfc822" entity. The message header fields are > always US-ASCII in any case, and data within the body can still be > encoded, in which case the Content-Transfer-Encoding header field in > the encapsulated message will reflect this. Non-US-ASCII text in the > headers of an encapsulated message can be specified using the > mechanisms described in RFC 2047.
From Piotr Masłowski to ~sircmpwn/public-inbox
Hello, First of all, congratualtions on completing Bunnix! I can confirm it boots on a ThinkPad T480 (UEFI mode, with the bootloader, kernel and initramfs all loaded from the ESP – since I didn't have a spare USB flash drive at hand to flash the ISO to). Since the OS includes a C compiler, I was wondering if Bunnix should (in principle) be capable of building Linux at this point. If so, it could be quite a major boost for the bootstrappable builds project. Ever since "Full Source Bootstrap" had been achieved, it is possible to build an almost complete Linux distribution without trusting a single prebuilt compiler. Instead only using source code and a single 357-byte-long, hand-written binary.
From Piotr Masłowski to ~postmarketos/upstreaming
On Wed Oct 11, 2023 at 1:35 AM CEST, Caleb Connolly wrote: > On 10/10/2023 23:53, Piotr Masłowski wrote: > They don't need to be correct, you don't need to complicate it, you just > need a value that plays nice. When it comes down to it you're much more > likely to be constrained by UI layout limitations by not being able to > model the precise corner curves of your device. The difference between a > circular and elliptical arc is negligible in all real world use cases. Well, with a large, weirdly-shaped display the curve will have to pass through more-or-less the right pixels for things like a-couple-px-thick frame to look right. I would expect e.g. a smartwatch UI to sometimes want to draw a constant-width frame along the screen border. Using a significantly different curve there will break that, so you would need
From Piotr Masłowski to ~postmarketos/upstreaming
On Tue Oct 10, 2023 at 10:36 PM CEST, Caleb Connolly wrote: >> So why am I writing all of this? Well, the problem I see is that any >> shape-based approach will likely suffer from both accuracy and >> complexity issues. Describing curves is hard and processing them is >> not something that should be included in e.g. whatever handles VTs. > > My proposal here doesn't require processing curves or doing any > complicated calculations. If you know that the display has a 30px radius > on all corners, you can adjust the VT to not use the top 30px of the > screen and it will start exactly where the radius stops. Just a nitpick, but on a round smartwatch this approach will give you a $width × 0px famebuffer ;D
From Piotr Masłowski to ~postmarketos/upstreaming
Hi Caleb, Thanks for posting this. I've been meaning to chime in on the discussion about notches and co. for months now, so this makes a perfect opportunity to finally do so. On Mon Oct 9, 2023 at 7:32 PM CEST, Caleb Connolly wrote: > Some folks have previously suggested that this information belongs in > userspace and not in devicetree. I would like to be clear that > devicetree is for describing hardware, and parts of a display which can > never actually be seen are very much properties of the underlying > hardware.
From Piotr Masłowski to ~sircmpwn/writefreesoftware.org
Hello I've sent a v2 for one of the patches from my last series. But since quite a few points I brough up in various earlier emails remain untackled, I'd like to try to gather them all in one place. Some of them will require me (or someone else) to propose patches. Other are questions or similar matters I'd like to see explained. Incidentally, there are many submissions that appear unresolved. Patches marked as 'PROPOSED', e-mails without a single reply and improvement/bug reports that have not been acted on. Some of course have been obsoleted or dealt with and are simply not marked as such, but that isn't
From Piotr Masłowski to ~sircmpwn/writefreesoftware.org
"[Copyleft licenses] ensure your software remains free" – 3rd person singular sentences didn't really fit here. --- > +1 but conflicts with rejected 5/6 Everything remains the same, except for 'copyleft disadvantages' which had to be turned into actual sentences. content/learn/participate/choose-a-license.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/learn/participate/choose-a-license.md b/content/learn/participate/choose-a-license.md [message trimmed]
From Piotr Masłowski to ~sircmpwn/writefreesoftware.org
"[Copyleft licenses] ensure your software remains free" – singular tense didn't really fit here. --- content/learn/participate/choose-a-license.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/content/learn/participate/choose-a-license.md b/content/learn/participate/choose-a-license.md index bf53102..c728175 100644 --- a/content/learn/participate/choose-a-license.md +++ b/content/learn/participate/choose-a-license.md @@ -36,9 +36,9 @@ incorporate their improvements back into your version. For more details, see ### Advantages [message trimmed]
From Piotr Masłowski to ~sircmpwn/writefreesoftware.org
--- content/learn/participate/choose-a-license.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/learn/participate/choose-a-license.md b/content/learn/participate/choose-a-license.md index 15de87e..bf53102 100644 --- a/content/learn/participate/choose-a-license.md +++ b/content/learn/participate/choose-a-license.md @@ -46,8 +46,9 @@ incorporate their improvements back into your version. For more details, see ### Disadvantages * Less attractive to businesses * Must consider license compatibility for reuse [message trimmed]
From Piotr Masłowski to ~sircmpwn/writefreesoftware.org
--- content/learn/participate/assets.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/learn/participate/assets.md b/content/learn/participate/assets.md index b8d8952..7a09f30 100644 --- a/content/learn/participate/assets.md +++ b/content/learn/participate/assets.md @@ -13,13 +13,13 @@ are compatible with free software licenses. ## Creative Commons Most multimedia assets -- images, audio, videos, writing, and so on -- are suitable for use with [Creative Commons][0] licenses, which include configurable suitable for use with [Creative Commons][cc] licenses, which include configurable [message trimmed]