From Cosmo Borsky to ~sircmpwn/public-inbox
Pandoc is one way to translate an HTML body to text: pandoc -f html -t plain You can also reference aerc which has an HTML filter that uses w3m: https://git.sr.ht/~rjarry/aerc/tree/master/item/filters/html May 8, 2022 11:09:35 Matthew Johnson <johns945@gmail.com>: > Hello, Do you know a way to 'render' a html email into plain text. > Mutt seems to do exactly what I would like to do with incoming html > emails and then I would like to be able to open it in Common Desktop > Environment (CDE)'s mailier program. CDE is a unix windows manager. > -Matthew
From Cosmo Borsky to ~sircmpwn/sr.ht-discuss
I think it is good to have this discussion, however (as mentioned before) it has been reasonably answered multiple times: on the list, irc, and maybe other medium. Apr 16, 2022 14:33:37 DJ Chase <u9000@posteo.net>: > That document also specifies that... The GNU document does not seem to be used as a direct source for Sourcehut's methology. > Yes, but there are accepted variations, as mentioned in my most recent > email. It is sufficient for projects to choose their conventions, such as
From Cosmo Borsky to ~sircmpwn/public-inbox
> The issue I have is with the notion of "while you're there." Is this > supposed to mean "while you have the irc window open in front of you?" Not necessary, just that you are online with a client running in the {fore,back}ground. Almost all IRC clients will notify you if you are mentioned or DCC'd. On the other hand, there are better channels for support/communication, like email! Or mailing lists. > I have used IRC a bit, but only for asking questions. The issue I see is > as the replier. If there is no backlog, how do you "check in" on the
From Cosmo Borsky to ~sircmpwn/alpine-aports
--- testing/chafa/APKBUILD | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 testing/chafa/APKBUILD diff --git a/testing/chafa/APKBUILD b/testing/chafa/APKBUILD new file mode 100644 index 0000000000..bafd4f4b0a --- /dev/null +++ b/testing/chafa/APKBUILD @@ -0,0 +1,28 @@ # Contributor: Cosmo Borsky <me@cosmoborsky.com> # Maintainer: Cosmo Borsky <me@cosmoborsky.com> pkgname="chafa" [message trimmed]
From Cosmo Borsky to ~sircmpwn/alpine-aports
--- testing/brillo/APKBUILD | 47 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 testing/brillo/APKBUILD diff --git a/testing/brillo/APKBUILD b/testing/brillo/APKBUILD new file mode 100644 index 0000000000..ebd693b5f1 --- /dev/null +++ b/testing/brillo/APKBUILD @@ -0,0 +1,47 @@ # Contributor: Cosmo Borsky <me@cosmoborsky.com> # Maintainer: Cosmo Borksy <me@cosmoborsky.com> pkgname="brillo" [message trimmed]
From Cosmo Borsky to ~sircmpwn/alpine-aports
This patch comes from a fork of redshift by minus.
The patch was edited to remove .gitignore, .travis.yml, and appveyor.yml
changes.
It didn't quite make sense to fork this package to add in one (large) patch. If
that is the desired action, do let me know.
It has been almost 18 months since this patch for Wayland support was
submitted to redshift with little interaction from the redshift developer,
The patch seems to have been tested by various users, and is
available in upstream repositories for Arch and other distros.
NOTE: I have only tested this on Sway/Wayland. I would advise testing on X11
and other supported platforms before merging.
[message trimmed]
From Cosmo Borsky to ~sircmpwn/alpine-devel
If it makes any difference, I am willing to contribute time and resources for SourceHut related Alpine development.
I think it is good to keep to one platform. GitLab is a mature suite which is familiar to a lot of developers, although aspects of it are proprietary.
SourceHut is in alpha, still in (very) active development, and many pain points have been and are being alleviated, on top of it being full FOSS.
However, since there are a good amount of developers contributing patches to the aports list, it makes sense to keep the list knowing that review may take time, and have developers/reviewers use the platform they are comfortable with until several pain points are resolved.
It would be good to put together a comparison list between GitLab and SourceHut that covers what each platform does well, what could be worked on, and what it does not do well.
>From this email thread, what I see as things that need to be worked on with SourceHut are:
- CI builds for patches submitted via list
- Fix compatibility with various hosts, eg Gmail
- Offer alternative methods for submitting patches, for example via web api if SMTP is blocked on a network.
From Cosmo Borsky to ~sircmpwn/alpine-devel
We shouldn't be so hot on removing the lists if they are not getting attention. If the mailing list goes unattended, pinging devs should be OK. If a contributor chooses to make a GitLab account and submit a patch as a PR, they should be able to. If a contributor would like to email a patch in, they should be able to. This seems more like the mailing list is not used extensively by devs/maintainers because it does not fit their workflow, be it testing patches, merging patches, etc. IMO, we should discuss what could be done to fit the developer's workflow and be more inclusive of those working on the mailing list. I've started to adapt a workflow that caters to both systems: the ability to mail and test mailed-in patches, and the ability to ease submitting PRs in eg. GitLab. Keep in mind the lists are powered by SourceHut, which is still in its early days. If you have ideas that would improve mailing list flow, submit a PR to SourceHut. Here is a task related to this thread: https://todo.sr.ht/~sircmpwn/dispatch.sr.ht/29
From Cosmo Borsky to ~sircmpwn/sr.ht-discuss
This looks good. The user vs org pricing distinction is great and much easier to imagine scaling. What are the implications for an organization looking to self-host SourceHut? Is it fine as long as they are within the GPL? What happens if a user or org would stop paying? Are their resources (eg. git, wiki, lists) still active? Do they turn read only? Would there be a grace period?
From Cosmo Borsky to ~sircmpwn/sr.ht-discuss
> This is a good idea. Need to think about how to balance it for ad-hoc > organizations of users, which don't map onto real-life organizations > with a budget to pay for things like this, but it's a better model than > what I had in mind for sure. Are ad-hoc organizations expecting to use more resources than companies/larger orgs? My thinking behind this is that resources are sort of freely available to sourcehut users, where limits are on machine time and not exactly usage of resources (though I may be wrong, I have lurking for the better part of a year). If anything, SourceHut could sponsor organizations with more resources or a discounted/free rate. Maybe adapting Migadu's tiers, where users are roughly limited by a resource (I.e. emails out per day), and if they hit that limit a courtesy notification would ask the user to upgrade to the next plan, and service would be cut back for the rest of the day if a % above the limit is hit. A rough pricing model could be: "Open Source" - organizations that strictly work on open source could be sponsored by SourceHut (similar to a user being sponsored by Drew), where they would have the same limits as the "introductory organization" tier. This group could also be used for ad hoc orgs, where it isn't one sole entity but a group of source hut users pooling a project together (eg. SourceHut itself). "Introductory" - $25/mo, includes 3 SourceHut user sponsors, and offers 20 Git repos, 20G total Git storage, 50 dispatch events per day, and 20hrs of build time a week. "Established" - $75/mo, 10 SourceHut user sponsors, unlimited Git repos and 100G total Git storage, 200 dispatch events per day, ...